Back
[03:45:11] <erasmo> helo
[03:45:34] <erasmo> I have a problem with lcnc latency
[03:46:29] <erasmo> My motherboard i a Gigabyte Ga-p35-ds3r
[03:46:59] <erasmo> under ubuntu 10.04 in lcnc i have hudge latency
[03:47:13] <erasmo> but under ubuntu 8.04 latency is ok
[03:47:47] <erasmo> is there any tool for logging what kind of program/hardware causes latency issues?
[03:51:35] <memleak> erasmo, to determine exact cause of latency jitter it's quite of a pain. how bad of latency do you get with 10.04 ?
[03:52:44] <erasmo> memleak: ith around 117000 ns for base thread
[03:53:04] <memleak> ah, something that big will be quite obvious to debug most likely.
[03:53:22] <memleak> post output of dmesg and cat /proc/interrupts to a paste site (pastebin, dpaste, fpaste, etc)
[03:53:53] <erasmo> ok ill do it,
[03:54:53] <memleak> thanks!
[03:55:23] <memleak> how long did you run latency-test on 8.04 ?
[03:55:40] <memleak> and how long does it take until latency gets very bad?
[03:57:08] <erasmo> this is dmesg
http://pastebin.com/austFjub
[03:59:23] <erasmo> cat /proc/interrupts
http://pastebin.com/5wZxr4s0
[04:00:59] <erasmo> I ran latency test for few seconds
[04:01:45] <erasmo> the weird thing is overruns happends every one-two seconds
[04:02:03] <memleak> that's a power management issue. PM timers are completely hosed: LOC: 330541 140096 Local timer interrupts
[04:02:44] <erasmo> I did turn PM in bios so it should not be an issue
[04:03:13] <memleak> some CPUs need minimal ACPI support for RT
[04:03:59] <memleak> for a core 2 duo that's a 64-bit CPU. turn ACPI on in BIOS and see if its better.
[04:04:16] <erasmo> ok Ill try
[04:04:20] <memleak> thanks
[04:04:21] <erasmo> thanks :)
[04:05:31] <memleak> without ACPI on some systems, the kernel doesn't know how to handle timers at all and you'll get terrible performance.
[04:06:01] <memleak> even outside of an RT system. compiling a kernel without ACPI support on a CPU that generally needs it can take twice as long.
[04:11:18] <erasmo> is there a way to unload local timer interrupts from kernel or disable it
[04:11:19] <erasmo> ??
[04:11:50] <memleak> you want those interrupts..
[04:12:13] <memleak> they're supposed to be there. without local timer interrupts i don't think TSC and all that other stuff would work.
[04:12:40] <erasmo> ok
[04:13:57] <erasmo> but if PM solution fails what then?
[04:14:19] <erasmo> is there any chance to make it work wright?
[04:14:30] <memleak> if ACPI is ON in BIOS, it should work fine.
[04:14:48] <memleak> that's the only issue I see.
[04:16:49] <memleak> if latency is still bad after enabling ACPI, repost new cat /proc/interrupts and dmesg output
[04:18:10] <memleak> if you necessarily need ACPI and all power management off, you'll need to switch to older hardware, but in my experience, new hardware with ACPI on fixes your exact problem.
[04:18:31] <memleak> turning off ACPI entirely on anything remotely recent hoses everything hands down.
[04:20:08] <memleak> I ran coreboot and FILO once on an MA785GM-US2H board with all timers off, no SMI, no ACPI, absolutely no power management tables at all, stripped out of the kernel, running it as bare metal as possible.. complete disaster.
[04:20:51] <erasmo> is this motherboards manufacturer tool to secure non-acpi system to run?
[04:21:25] <memleak> can you rephrase the question? i don't fully understand.
[04:22:46] <erasmo> i suspect the fact that if you run pure-hardware (acpi independant software) manufacturers secure their product to be damage-resistant
[04:23:06] <erasmo> so they decrease system speed to protect the hardware
[04:23:21] <erasmo> if the acpi/pm is turned of
[04:24:09] <erasmo> this is what i suspect
[04:26:12] <memleak> it's not intentional or on purpose, the CPU just doesn't know how to fully function correctly without ACPI timers
[04:26:38] <memleak> because it's the same result even with a non-factory BIOS.
[04:28:58] <erasmo> so without the watchdog (ACPI / PM) system slows down
[04:31:06] <memleak> i don't fully understand the whole mechanism, CaptHindsight knows all this stuff better than I do.
[04:31:51] <memleak> i don't think ACPI timers fall under the category of a watchdog though.
[04:32:26] <memleak> according to the linux kernel at least they're two totally different things.
[04:33:06] <memleak> watchdog support in kernel and ACPI / PM are totally different. it looks as a watchdog as more of an actual hardware device. ACPI / PM is just a table.
[04:34:25] <memleak> yet again i'm not an expert on all this stuff. I just know how most of RTAI works, not so much at BIOS / hardware level though.
[04:43:02] <erasmo> thanks for explaining me all this
[04:43:23] <erasmo> I'm no expert either
[04:43:25] <erasmo> :)
[04:50:04] <erasmo> it seems that changes in BIOS had brought no effect
[04:51:39] <erasmo> thanks for your help memleak
[05:01:15] <memleak> :/
[05:01:33] <memleak> repost dmesg and proc/interrupts
[05:01:54] <memleak> same exact issue?!
[05:03:10] <memleak> RTAPI: ERROR: Unexpected realtime delay on task 1 ?
[05:03:59] <erasmo> yes, latency issue
[05:04:13] <erasmo> but in bios I have no acpi on/off switch
[05:04:57] <erasmo> I think I should try to upgrade BIOS version and then try to make some changes
[05:05:04] <memleak> do you have any power saving features enabled?
[05:05:10] <erasmo> yes
[05:05:12] <memleak> hyper-threading?
[05:05:15] <erasmo> no
[05:05:22] <erasmo> no HT
[05:05:32] <erasmo> I have HT disabled
[05:05:35] <memleak> what changes did you make in BIOS?
[05:07:56] <memleak> Plug and play is off in BIOS it seems too.. that shouldn't be. that might be why.
[05:08:04] <erasmo> I disabled all functions: HDD SMART, devices wake up, disabled automatic CPU speed adjustment
[05:08:45] <memleak> DES energy saver stuff?
[05:09:31] <erasmo> There is no DES option in my BIOS
[05:11:11] <memleak> MP table, C1E, virtualization support?
[05:11:47] <erasmo> I did forgot I disabled virtualization support
[05:11:53] <memleak> 8254 or any APIC options? HPET?
[05:12:05] <erasmo> disabled HPET
[05:12:13] <memleak> ah! you need HPET
[05:12:42] <erasmo> but with HPET on I had the same issues
[05:12:50] <memleak> are you sure?
[05:12:56] <erasmo> yes
[05:13:47] <erasmo> give me 5 minuets and I'll tell you for sure if there is difference with HPET on/off
[05:14:13] <memleak> disable any CPU stepping
[05:14:20] <erasmo> disabled
[05:14:32] <erasmo> CPU stepping disabled
[05:14:52] <memleak> with hpet on, post dmesg, cat /proc/interrupts and dmidecode
[05:15:05] <erasmo> it is strange on ubuntu 8.04 I had no problems at all
[05:15:09] <memleak> (dmidecode must be installed and run with sudo)
[05:15:34] <memleak> timers are messed up in 10.04
[05:15:49] <memleak> i dont know why for your board though (yet)
[05:16:22] <erasmo> is there any chance to fix timers in later distros?
[05:16:46] <memleak> well it might work with 10.04 with seb's debs.
[05:17:50] <memleak> where are they again...
[05:18:34] <memleak> ah
http://highlab.com/~seb/linuxcnc/rtai-for-3.4-prerelease/
[05:19:32] <memleak> linux-image-3.4.55-rtai-1_1_i386.deb linux-headers-3.4.55-rtai-1_1_i386.deb and rtai-modules-3.4.55-rtai-1_3.9-shabby-memleak-2013.08.05_i386.deb
[05:20:39] <erasmo> you want me to try with those images?
[05:20:42] <memleak> yes
[05:20:57] <memleak> with HPET
[05:21:05] <erasmo> ok I'll see what I can do
[05:21:21] <memleak> if it doesn't work, repost dmesg and cat /proc/interrupts
[05:21:33] <memleak> you'll need to recompile linuxcnc though
[05:21:47] <erasmo> ok
[05:21:58] <memleak> sudo apt-get build-dep linuxcnc && sudo apt-get install git build-essential
[05:22:54] <memleak> git clone git://git.linuxcnc.org/git/linuxcnc.git && cd linuxcnc && ./autogen.sh && ./configure
[05:23:30] <memleak> if successful, run make and then . ./scripts/rip-environment && latency-test
[05:24:06] <erasmo> ok
[05:24:16] <memleak> cd linuxcnc should be cd linuxcnc/src btw
[05:24:56] <memleak> after make then cd .. && . ./scripts/rip-environment
[05:25:51] * memleak should just write a bash script that automatically does all this
[09:56:07] <cradek> huh, another wiki spammer today
[09:56:10] <cradek> it's picking up
[09:56:16] <jepler> :-/ we must have gotten on a list
[09:56:18] <cradek> the isp of the previous one never answered me
[09:56:21] <jepler> of course not
[09:56:49] <jepler> does it look like another hu-mann?
[09:56:58] <cradek> yes
[09:57:05] <jepler> god that job sucks worse than mine
[09:57:10] <cradek> no kidding
[09:57:34] <cradek> this was just one page. the previous guy spent hours and hours - I think he intended to do all the pages one at a time.
[09:58:49] <cradek> for the one page, I just reverted it in the wiki software, which leaves the spam in the history. I wonder if I should restore it to pre-spam state instead.
[09:59:02] <cradek> I'm not sure whether having it in the history helps the losers somehow
[10:01:30] <jepler> the spammy version of the page is available just by clicking links, so it's likely to be indexed by google and still count as incoming links to their site which is good SEO
[10:02:05] <cradek> I'll restore it then
[10:02:20] <cradek> unfortunately I don't think there's a way to selectively nuke history
[10:02:37] <jepler> no clue
[10:03:18] <cradek> huh, rsync doesn't work inside .zfs/snapshot/some-date/
[10:03:21] <cradek> rsync: getcwd(): No such file or directory (2)
[10:05:38] <cradek> wiki fixed
[10:07:47] <jepler> huh yuck
[10:09:16] <cradek> it goes off madly statting .. and back up the tree for some reason
[10:10:23] <jepler> same on debian-kfreebsd
[10:14:43] <jepler> internet suggests that making snapshots visible can allow rsync to succeed
[10:14:51] <jepler> jepler@zaphod:~/.zfs/snapshot/2013-08-14_0900$ /bin/pwd
[10:14:51] <jepler> /bin/pwd: couldn't find directory entry in `../../..' with matching i-node
[10:15:16] <jepler> "readlink -f ." also fails
[10:17:57] <archivist> spam is one of the reasons I am beginning to disfavour wikis and forums, stuff needs moderating these days
[10:18:44] <cradek> I wonder if it's looking for .rsync-whatever filter files in the parents
[10:21:40] <cradek> yes that does "fix" it
[10:24:42] <cradek> archivist: the wiki is low enough traffic and the changes are summarized on one page that I don't mind checking it daily
[10:25:05] <cradek> archivist: but keeping up with the forum is quite a task and I'm happy I don't have to do it
[10:25:16] <archivist> the problem is getting worse though
[10:25:33] <cradek> which do you mean specifically?
[10:26:07] <archivist> spammers going after any site where they can add content
[10:26:35] <cradek> well we all know web 2.0 was a mistake
[10:28:10] <cradek> (I'm not sure I'm not serious)
[10:30:54] <archivist> it is a shame that the wiki, forum and blog comment are used for spam it has spoiled it for the many
[13:32:08] <awallin> mhaberler: around? (or anyone who has compiled a xenomai kernel on ARM?)
[13:32:17] <mhaberler> yes
[13:32:30] <mhaberler> which platform?
[13:32:47] <mhaberler> not on arm, rather cross for arm
[13:36:16] <awallin> I am wondering if this is for mere mortals...
https://www.olimex.com/forum/index.php?topic=1051.msg5152#msg5152
[13:37:24] <awallin> which, I guess, points us here:
https://www.olimex.com/forum/index.php?topic=812.0
[13:39:06] <awallin> so there is a 200k line patch for a 3.4.24 kernel, and I should apply the "standard xenomai procedure"
[13:52:09] <KGB-linuxcnc> 03git 05unified-build-candidate-1 9dab7ae 06linuxcnc 10src/Makefile * src/Makefile: fix compilation error on x86/wheezy
[13:55:33] <mhaberler> ah, welcome.
[13:55:46] <mhaberler> is this an olinuxino?
[13:57:31] <mhaberler> talk to Eric Keller (emc-developers), he's chasing the olinuxino
[13:58:12] <mhaberler> the xenomai wiki is pretty good on this, and the list is helpful (provided you've read the docs, otherwise: fish slapping ;)
[13:58:32] <awallin> yes, I have an A13 olinuxino now and getting an A10S probably also
[13:59:16] <mhaberler> so you are in the 'let's chase a working xenomai kernel' business then.. I didnt warn you by any chance?
[13:59:30] <mhaberler> I have no idea how far Eric got
[14:00:49] <awallin> well, any embedded platform would do I guess, but the olinuxino boards are almost the only ones offered with affordable touch-screens
[14:02:28] <CaptHindsight> awallin: just FYI the Olixino boards that use the Allwinner arm socs are the same soc's found in many low cost tablets
[14:03:07] <CaptHindsight> there's quite a large community that works on Allwinner Linux support
[14:03:24] <awallin> CaptHindsight: yeah, they seem to run various flavors of android also... no real-time available there I guess
[14:05:51] <awallin> I want to connect some ADCs and DACs to this controller with SPI. olimex forum seemed to indicate that bit-banged SPI on almost any GPIO pins will work
[14:06:39] <CaptHindsight> I lost track a few months ago for the allwinner, but that work should really start to move again
[14:07:11] <CaptHindsight> the SPI port on the Allwinner soc's works up to 100MHz
[14:07:34] <CaptHindsight> but olimex uses the stripped down versions of the devices
[14:07:40] <awallin> someone on the forum said the built-in SPI suffers from latency...
[14:08:21] <CaptHindsight> pcw was working on a FPGA card for the cubieboard, it uses the A20 4-core
[14:08:36] <CaptHindsight> pretty sure he said it worked with SPI
[14:09:14] <CaptHindsight> http://cubieboard.org/
[14:09:38] <CaptHindsight> http://linux-sunxi.org/Cubieboard
[14:11:04] <CaptHindsight> many of the same devs on the forums for olimex, cubie and arm-netbook
[14:11:38] <awallin> I really like the lcd screens that work with olinuxino - for lab-instrument applications where it's useful to show status/info on the screen
[14:11:57] <linuxcnc-build_> build #1271 of hardy-amd64-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1271 blamelist: Michael Haberler <git@mah.priv.at>
[14:12:13] <linuxcnc-build_> build #1267 of hardy-i386-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1267 blamelist: Michael Haberler <git@mah.priv.at>
[14:13:08] <linuxcnc-build_> build #1269 of hardy-i386-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1269 blamelist: Michael Haberler <git@mah.priv.at>
[14:13:11] <CaptHindsight> http://www.xenomai.org/pipermail/xenomai/2013-February/027801.html
[14:14:31] <awallin> yes, that looks like a copy of the olimex forum post
[14:15:14] <CaptHindsight> so i-pipe is working so the rest is tool chain hell
[14:16:05] <CaptHindsight> i was just checking a few other allwinner forums, pretty much the same info...
[14:17:14] <awallin> I wish there were "hold my hand" type of instructions for n00bs.. :)
[14:18:26] <CaptHindsight> maybe in a couple of months
[14:18:58] <awallin> eh so I get about 20+ lines of "error: patch failed" with that..
[14:19:04] <CaptHindsight> we are going to jump back into realtime for ARM next month for the Allwinner parts
[14:22:56] <CaptHindsight> awallin: I'd ask on the forum, maybe somebody will post some more detailed build instructions
[14:24:32] <awallin> hm, yeah
[14:25:02] <jepler> if the patch doesn't apply no amount of instructions will fix it
[14:26:40] <CaptHindsight> I was thinking it might start up discussions for what what works with what and how to build
[14:27:54] <awallin> the other option for my SPI ADC/DAC project would be x86 hardware and a Mesa FPGA-card. a bit overkill. And would need to write new HDL for the Firmware for SPI reads and writes.
[14:36:24] <skunkworks> micges, any time to look at the 7i80 yet?
[14:37:38] <micges> not really but what's up?
[14:38:48] <micges> you mean that 7i80 works better on intel eth boards?
[14:40:48] <micges> (saw that in log)
[14:46:31] <skunkworks> I have 2 systems (12.04 and 10.04) 12.04 will not run the hostmot driver - the other doesn't seem to send the config (10.04)
[14:46:41] <skunkworks> I can get more info again - tomorrow
[14:47:06] <micges> sure
[14:50:05] <CaptHindsight> https://www.osadl.org/fileadmin/dam/rtlws/12/Brown.pdf How fast is fast enough? Choosing between Xenomai and Linux for real-time applications
[14:51:41] <CaptHindsight> unfortunately they used the magic "CodeSourcery cross-compilation toolchain", but the results are interesting
[14:52:52] <jepler> that'd be dandy if somebody would put in the time to make linuxcnc cross compile
[14:55:03] <linuxcnc-build_> build #470 of precise-i386-realtime-rip is complete: Failure [4failed compile get-dmesg] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/470 blamelist: Michael Haberler <git@mah.priv.at>
[14:55:06] <CaptHindsight> our plan is to use crosstool-ng and avoid the magic, and we'll post the howto
[14:57:02] <CaptHindsight> all projects for the fall
[15:01:11] <linuxcnc-build_> build #1265 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1265 blamelist: Michael Haberler <git@mah.priv.at>
[15:10:32] <andypugh> What's the magic to force a merge of 2.5 up to master? (I have a feeling that yesterdays change might not merge cleanly)
[15:13:12] <cradek> git checkout master; git merge v2.5_branch
[15:13:53] <jepler> and you're correct that there are conflicts to be resolved by a human
[15:18:07] <KGB-linuxcnc> 03git 05unified-build-candidate-1 dd3f7a5 06linuxcnc 10src/ 10emc/nml_intf/debugflags.h 10emc/rs274ngc/rs274ngc.hh 10emc/rs274ngc/rs274ngc_pre.cc * interp: rename LOG_PID to LOG_PROCESSID - collision with syslog(3)
[15:23:06] <andypugh> Bah! So what do I need to do to resolve the conflicts non-locally?
[15:26:16] <linuxcnc-build_> build #1272 of hardy-amd64-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1272 blamelist: Michael Haberler <git@mah.priv.at>
[15:26:19] <linuxcnc-build_> build #1268 of hardy-i386-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1268 blamelist: Michael Haberler <git@mah.priv.at>
[15:26:51] <linuxcnc-build_> build #1270 of hardy-i386-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1270 blamelist: Michael Haberler <git@mah.priv.at>
[15:27:24] <mhaberler> andy: suggested:
http://blog.wuwon.id.au/2010/09/painless-merge-conflict-resolution-in.html
[15:29:42] <jepler> that page suggests to use a GUI to resolve conflicts, but personally I disagree with that
[15:31:08] <KGB-linuxcnc> 03TODO: deletor 05v2.5-lxrt-OPT-O0-breakage de6b60a 06linuxcnc 04. * branch deleted
[15:33:44] <KGB-linuxcnc> 03chris 05v2.5_branch e627a38 06linuxcnc 10src/emc/usr_intf/touchy/mdi.py * Touchy: MDI support for M61
[15:34:00] <jepler> also meld & sleep; meld & sleep; meld is a weird script--what are the sleeps for?
[15:34:46] <jepler> andypugh: if you're uncomfortable doing the merge I'm happy to do it for you.
[15:35:54] <cradek> I recommend [merge]conflictstyle = diff3 and [merge]tool = your-text-editor, [mergetool "your-text-editor"]cmd = your-text-editors-name $MERGED
[15:39:07] <jepler> (at $DAY_JOB, we found at least that *starting* people with the GUI merge tool prevented them understanding what was going on, and led to poor results)
[15:39:36] <jepler> (they may well be useful after you understand what's going on, except that the main operation meld facilitates -- take one side or the other -- is typically just wrong)
[15:40:00] <jepler> (to its credit, the article does try to cover that concept)
[15:41:23] <cradek> the article does say to enable conflictstyle diff3
[15:41:38] <cradek> that is the single most important piece of advice, and you're utterly doomed without it
[15:58:35] <andypugh> jepler: I would be happier if someone competent did it. The actual conflict is very simple to see, and the patch was very small. It's basically the mechanics of the process I am worried by
[16:02:34] <jepler> andypugh: does this part of the diff look sane?
[16:02:35] <jepler> http://pastebin.com/QVBe4NhA
[16:04:22] <andypugh> Yes, that looks right. Though I am not clear id the __ parts are actually wise ot correct. (A comment in the rtapi.h says that the __ versions are the ones to use)
[16:04:37] <cradek> my guess:
http://pastebin.com/mAtxQrBv
[16:04:39] <jepler> I'll believe the comment, then (it's what you did in 2.5 right?)
[16:04:59] <andypugh> Yes, and it works. I just haven't used the __ anywhere else.
[16:05:46] <andypugh> As long as anything that said "long" is now explicitly 32-bits it should be fine.
[16:07:12] <jepler> oh yes, cradek's merge is correct(?) in one way mine isn't: he changed the type of index_cnts too
[16:07:32] <jepler> cradek: push ahoy
[16:08:07] <cradek> whee
[16:08:08] <jepler> (by which I mean you should push)
[16:08:09] <KGB-linuxcnc> 03andy 05master a9fb0a0 06linuxcnc 10src/hal/drivers/ 10mesa-hostmot2/hostmot2.h 10mesa-hostmot2/resolver.c
[16:08:09] <KGB-linuxcnc> Fix a Hostmot2 Resolver bug in 64 bit builds.
[16:08:09] <KGB-linuxcnc> Do not assume that "long" is 32 bits in all systems. this bug resulted in the
[16:08:09] <KGB-linuxcnc> resolver module being utterly unusable, with the apparent resolver angle varying
[16:08:11] <KGB-linuxcnc> randomly by thousands of turns
[16:08:13] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[16:08:32] <KGB-linuxcnc> 03chris 05master e627a38 06linuxcnc 10src/emc/usr_intf/touchy/mdi.py * Touchy: MDI support for M61
[16:08:38] <KGB-linuxcnc> 03chris 05master 316ddab 06linuxcnc 10src/hal/drivers/ 10mesa-hostmot2/hostmot2.h 10mesa-hostmot2/resolver.c * Merge branch 'v2.5_branch'
[16:08:50] <cradek> andypugh: it'd be even better if you'd test master now :-)
[16:09:24] <cradek> also would be better if I had tried building it
[16:09:29] <cradek> but you just can't have everything
[16:10:22] <andypugh> Hmm, I need to remeber if any of the PCs or SSDs scattered about are capable of running master..
[16:11:52] <linuxcnc-build_> build #471 of precise-i386-realtime-rip is complete: Failure [4failed clear-dmesg compile get-dmesg] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/471 blamelist: Michael Haberler <git@mah.priv.at>
[16:12:41] <cradek> eh that stupid thing
[16:16:44] <andypugh> I seem to be spending all my spare time doing clean installs of various combinations of 32 and 64 bit RTAI and Xenomai systems. It's getting a bit boring.
[16:17:28] <KGB-linuxcnc> 03jthornton 05v2.5_branch 08597ae 06linuxcnc 10docs/ 10(72 files in 12 dirs)
[16:17:29] <KGB-linuxcnc> Docs: add note to untranslated Spanish chapters
[16:17:29] <KGB-linuxcnc> add info for translators on how to get the latest version
[16:17:29] <KGB-linuxcnc> of that chapter before starting a translation.
[16:17:30] <KGB-linuxcnc> Signed-off-by: John Thornton <jthornton@gnipsel.com>
[16:17:46] <KGB-linuxcnc> 03jthornton 05v2.5_branch 2eb0d98 06linuxcnc 10docs/html/gcode.html * Docs: add m61 to quick reference
[16:18:01] <linuxcnc-build_> build #1266 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1266 blamelist: Michael Haberler <git@mah.priv.at>
[16:18:15] * jthornton goes back to making chips :)
[16:31:22] <memleak> 64-bit RTAI doesn't compile with linuxcnc because of some SSE / sincos issue
[16:31:34] <memleak> andypugh do you have any idea how to fix that?
[16:31:40] <memleak> it's highly annoying..
[16:33:28] <andypugh> No, 64-bit RTAI is one of the variants I have not touched
[16:41:11] <memleak> "I seem to be spending all my spare time doing clean installs of various combinations of 32 and 64 bit RTAI and Xenomai systems." ?
[17:03:44] <linuxcnc-build_> build #472 of precise-i386-realtime-rip is complete: Failure [4failed clear-dmesg compile get-dmesg] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/472 blamelist: Chris Radek <chris@timeguy.com>, John Thornton <jthornton@gnipsel.com>
[17:10:05] <linuxcnc-build_> build #1267 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1267 blamelist: Chris Radek <chris@timeguy.com>, John Thornton <jthornton@gnipsel.com>
[17:16:21] <andypugh> Yikes! My Resolver index detection is completely and utterly bogus!
[17:20:31] <jepler> sssh don't tell anyone
[17:26:36] <KimK_3> I installed Seb's debs on 12.04(32), and although the new RTAI kernel is found during "sudo update-grub", it does not appear in the grub2 pick menu on startup. Picture of the contents of /boot at
http://imagebin.org/267621 I notice only the -51 kernel (which works) has a zipped image, the RTAI kernel does not. Any suggestions or advice appreciated.
[17:30:02] <memleak> KimK_3: does the /boot directory have the 3.4.55 kernels in them?
[17:31:06] <memleak> nevermid the pic shows.. sorry
[17:31:52] <memleak> for grub2 you're supposed to use sudo grub2-mkconfig -o /boot/grub/grub.cfg
[17:32:04] <KimK_3> No zipped image, but there are 55-rtai of config... , system.map... , and vmlinuz...
[17:32:37] <memleak> depending on how seb packaged it, it might not use an initrd
[17:32:56] <memleak> (inital ram filesystem / zipped file)
[17:33:41] <KimK_3> OK, I thought "sudo update-grub" was the rule, I'll try your command, brb
[17:33:43] <andypugh> jepler: Fix in 2.5 and go through the same merge conflict hassles as earlier? (It's the same part of the code, which is how I noticed it)
[17:34:10] <memleak> thats for grub 1
[17:34:16] <memleak> (0.97 i should say..)
[17:35:02] <andypugh> It might not even matter, as the behaviour is to clear the index and return the current absolute counts, to it isn't positionally wrong, it just happens at the wrong time.
[17:35:28] <KimK_3> sudo: grub2-mkconfig: command not found
[17:36:15] <memleak> grub-mkconfig ?
[17:36:30] <memleak> this is why i hate ubuntu.. THEY RENAME EVERYTHING
[17:38:17] <jepler> andypugh: if it's a bugfix you will want to see in 2.5, then yes. chris or I can help you with the merge again if you want
[17:38:53] <andypugh> It's actually a bugfix that needs to be fixed in different ways in 2.5 and master.
[17:39:07] <memleak> KimK_3:
https://github.com/ShabbyX/RTAI/blob/master/README.INSTALL#L179
[17:39:48] <andypugh> I would _prefer_ to fix it twice, if that is an option.
[17:41:32] <KimK_3> memleak: OK, that appeared to work, it printed a list as with "update-grub", let's see what the boot menu looks like. I'll be right back.
[17:42:30] <jepler> andypugh: if you want to fix it in 2.5, eventually somebody has to do the merge from 2.5 to master, so there's no saved effort by fixing it twice
[17:43:17] <andypugh> The problem is that the fix in 2.5 will break master.
[17:43:26] <andypugh> (but I can then fix master)
[17:47:48] <jepler> andypugh: do you mean it's logically different, or just that it's going to be complicated by other changes in code that is very nearby?
[17:47:56] <andypugh> The latter
[17:48:20] <KimK_3> memleak: The RTAI kernel still does not appear on the boot menu, so I'll try your second suggestion about manually editing the grub2 file(s). First a short break though, I'll be back in a bit.
[17:49:22] <jepler> andypugh: in that case I think a good first step is to fix it in v2.5 and then we can look together at what problems come up when merging to master
[17:49:35] <andypugh> There is a feature in Master to only "index" on every Nth electrical revolutio (for multi-turn encoders). That needs to be re-thought to suit the new detection method (count-up and count-down timers)
[17:54:40] <andypugh> It doesn't matter if you dither through index mutliple times in a single turn resolver. But you don't want to count every flip in a multi-turn one.
[17:55:44] <andypugh> I suspect that, actually, the problem is there in Master regardless of my other error.
[17:56:55] <andypugh> In my defence, I wrote that driver before I had any resolvers, and it was reported to be working...
[17:57:36] <linuxcnc-build_> build #1268 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1268 blamelist: Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>
[17:57:41] <skunkworks> excuses excuses...
[17:58:02] <skunkworks> ;?
[17:58:05] <skunkworks> heh
[17:58:08] <skunkworks> ;)
[17:59:44] <andypugh> How do I find out what went wrong?
[18:00:04] <andypugh> Clicking the link is not clearly indicating the problem?
[18:00:29] <jepler> andypugh: "build #1268" failed because "build #473" did; #473 failed because of a bug in the realtime kernel on precise, not because of anything you did
[18:00:32] <jepler> that's how I read it
[18:01:12] <jepler> andypugh: anyway, there is a way to make a "different" fix for v2.5 and for master. It starts by making the fix on v2.5_branch
[18:01:25] <andypugh> I am working on it now :-)
[18:02:02] <jepler> then in a separate branch, starting from v2.5 after your fix, you: 1. revert your fix with 'git revert' 2. merge master with 'git merge origin/master' 3. fix the bug again as required for master branch 4. merge this branch into master branch and push that
[18:02:52] <jepler> if that sounds a bit advanced that's OK, cradek or I can walk you through it
[18:04:58] <jepler> anyway, until seb reboots the "precise" builder, every checkin is going to report failure :-(
[18:06:40] <jepler> bbl, dinnertime
[19:20:51] <KGB-linuxcnc> 03andy 05v2.5_branch 6cae47a 06linuxcnc 10src/hal/drivers/mesa-hostmot2/resolver.c
[19:20:51] <KGB-linuxcnc> Use a less bogus way to detect "index" with Resolvers.
[19:20:51] <KGB-linuxcnc> For example, one that only happens once per rev.
[19:20:51] <KGB-linuxcnc> And fix an off-by-one error in the reverse direction too.
[19:20:52] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[20:06:19] <linuxcnc-build_> build #474 of precise-i386-realtime-rip is complete: Failure [4failed clear-dmesg compile get-dmesg] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/474 blamelist: Andy Pugh <andy@bodgesoc.org>
[20:11:44] <linuxcnc-build_> build #1269 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1269 blamelist: Andy Pugh <andy@bodgesoc.org>
[20:39:48] <KimK_3> memleak: I'm back. I read the file you pointed out, ShabbyX comes at it completely differently, from the manual compile end instead of debs. Since I'm doing this with Seb's debs, at what point (step number) should I jump into Shabby's list? I'm barely back, I haven't done anything with grub yet, still looking things over.
[20:46:16] <CaptHindsight> KimK: memleak is away until tomorrow
[20:47:26] <CaptHindsight> maybe someone else that stays current with ubuntu can help before then
[20:48:27] <CaptHindsight> KimK: are you just trying to get the realtime kernel to show up in grub2?
[20:49:12] <andypugh> I am reinstalling Lubuntu for the second time tonight. Well, this morning now. The first install has a system font too small to read (4 pixels high) and I can't see well enough to do anything more than log in.
[20:49:34] <andypugh> Probably an Intel GMA problem.
[20:50:11] <andypugh> KimK: The Resolver driver should work now.
[20:55:47] <KimK_3> CaptHindsight: Oh, OK. No problem, tomorrow is fine too. Yes, I would like the RTAI kernel to show up in grub. Now I'm not sure I've installed it/them correctly, I just installed Seb's debs, but then memleak pointed me to ShabbyX's readme, which is written around compiling from scratch, and he has many steps listed. I'll only need the later ones, but how late?
[20:58:59] <KimK_3> andypugh: Excellent, Andy, that's great news, thanks very much! Unfortunately I'm waiting for some Mesa cards and trying to get this E350N going for a side project, so it will be a couple of weeks or more before I get back around to the resolver project.
[21:04:52] <CaptHindsight> KimK_3: on ubunutu it might be grub-mkconfig -o /boot/grub/grub.cfg
[21:05:48] <CaptHindsight> http://www.theurbanpenguin.com/linux/ubuntu/07grub2.html
[21:12:34] <KimK_3> CaptHindsight: Yes, memleak recommended grub-mkconfig (etc) and that worked, but it may be tied with update-grub, because that seemed to work in the same way, and with the same results.
[21:21:34] <KimK_3> andypugh: Don't beat yourself to death, it must be getting late over there. To be continued tomorrow?
[21:23:23] <andypugh> It's only 3am
[21:30:06] <cradek> if seb's kernel debs don't cause it to show up in grub and be bootable, they are utterly broken, and I would be surprised to learn that
[21:30:09] <andypugh> X -configure segfaulted, but at least the xorg.conf it made resulted in fonts coming out more than 3 pixels high. Internet advice "make the fonts bigger in look and feel". And how am I meant to navigate "look and feel" when the fonts are literally illegible?
[21:30:22] <andypugh> Night all
[21:30:26] <skunkworks> night andy
[21:30:31] <cradek> I have the buildbot admin password and I can "Graceful Shutdown" that broken builder, but not reboot it
[21:30:32] <KimK_3> Goodnight Andy
[21:31:10] <cradek> but, I don't know whether that would make it better or worse (aka needing seb's help more urgently)
[21:32:55] <skunkworks> cradek: stella is going to be 1 monday.. That doesn't seem right...
[21:33:00] <KimK_3> cradek: I suspect I may have a "clean install" problem. Mine was a new (blank) drive, whereas Seb may have copied a needed file here or there on his system so that it was present where/when needed.
[21:34:45] <KimK_3> skunkworks: No, Sam, that doesn't seem right, lol. Congratulations to all of you!
[21:34:55] <cradek> skunkworks: wow, and I'm going to be 40 soon. I have a heck of a head start on her.
[21:35:22] <cradek> skunkworks: I feel sorry for her - growing up is really hard work and I'm quite glad to be done with it.
[21:37:07] <skunkworks> cradek: I turned 40 in june...
[21:37:15] <skunkworks> I forgot we are pretty close in age
[21:37:45] <skunkworks> I am going to be almost 60 when she graduates... (I don't know what to think about that) ;)
[21:39:54] <cradek> you started late...
[21:40:28] <skunkworks> sat on the fence too long..
[21:41:57] <KimK_3> cradek: What, the buildbot doesn't honor "sudo shutdown -r now" ?
[21:42:26] <cradek> I don't have a login to the VMs, only the buildbot web interface password
[21:42:44] <KimK_3> Ah.
[21:43:00] <cradek> if I poke the shutdown button I don't know if I can get it back (although I guess I doubt that's a worse situation than it just failing forever)
[21:43:21] <skunkworks> I thought zultron was getting the buildbot to restart the build.. Or is it a bit lower level than that?
[21:44:12] <KimK_3> Poke it when vacation is almost over anyway?
[21:44:33] <cradek> the precise-rt buildbot VM has a bogus kernel that goes nuts after a while
[21:44:50] <cradek> nobody knows why but a reboot fixes it for a while
[21:45:42] <cradek> well I shut it down.
[21:48:31] <cradek> linuxcnc-build_: force build --branch=v2.5_branch checkin
[21:48:32] <linuxcnc-build_> build forced [ETA 1h14m41s]
[21:48:32] <linuxcnc-build_> I'll give a shout when the build finishes
[21:48:44] <cradek> you're the best
[21:49:07] <KimK_3> ("Captain Ron", adding motor oil to a marine diesel engine, in the presence of the boat owner's two children:) Captain Ron: "Kids, a diesel engine likes its oil, like a sailor likes his rum." Kids: "Why is that, Captain Ron?" Captain Ron (pausing to think): "Well... nobody knows."