Back
[07:13:34] <quitte> So I made quite some progress setting up a debian live preempt_rt system. the latency test gives me about 100us max. and the menus are populated. but when I run strpconf - when it comes to testing the axis i get an error. AttributeError: 'module' object has no attribute 'kernel_version'
[07:56:20] <quitte> http://imgur.com/Jr82vMe this screenshot has the full error message
[07:59:04] <archivist> you cant run stepconf at the same time as latency test
[08:02:07] <quitte> latency test was started later, I think but I'll try again
[08:03:22] <quitte> no change
[08:14:52] <CaptHindsight> quitte: which cpu and chipset are you using?
[08:15:30] <quitte> CaptHindsight: a Pentium4 inside some Toshiba Satellite Laptop
[08:17:06] <CaptHindsight> most laptops get poor results since they use an EC and SMI which is connected over LPC
[08:17:13] <quitte> ICH5, I guess
[08:17:59] <CaptHindsight> (embedded controller) EC tends to add unexpected delays
[08:18:46] <quitte> CaptHindsight: at the moment I don't care about latency at all. I could move to another computer any time if necessary
[08:18:49] <CaptHindsight> try to kill as much power management as possible, speed stepping and virtualization
[08:21:44] <archivist> has stepconf been tested with that kernel
[08:32:22] <mhaberler> no, it relies on old assumptions - stepconf.py and pncconf.py need to be adapted for ub
[08:33:02] <mhaberler> halmodule exports a symbol based on build (sim and rt), and distinction isnt compile time anymore
[08:33:19] <mhaberler> which is why I created the linuxccncconfig.py module which replaces that
[08:35:26] <cradek> mhaberler: I don't see anything about fixing stepconf and pncconf on
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Todo-2.6 -- please add details if appropriate
[08:35:53] <mhaberler> I dont see either, first time I heard of this issue
[08:36:20] <cradek> thanks
[08:38:06] <quitte> I'll leave that here even if it seems that it's not useful anymore
http://pastebin.com/GWieJBGu
[08:38:52] <mhaberler> could you post /var/log/linuxcnc.log too
[08:39:10] <quitte> hmm insmod failed. of course it did since I'm a user. what did it try to load?
[08:42:07] <quitte> http://pastebin.com/evgf3bdH
[08:42:31] <mhaberler> Feb 13 16:18:05 debian msgd:0: hal_lib:10871:rt config string '0x378 out '
[08:42:32] <mhaberler> Feb 13 16:18:05 debian msgd:0: hal_lib:10871:rt Failed to open parallel port /dev/parport0: No such file or directory
[08:43:00] <quitte> i just saw that too
[08:43:10] <quitte> the answer to what insmod tried to do?
[08:43:39] <mhaberler> yes, hal_parport failed, see next line:
[08:43:40] <mhaberler> Feb 13 16:18:05 debian msgd:0: rtapi_app:10871:user rtapi_app_main(hal_parport): -19 No such device
[08:49:33] <skunkworks> linuxcnc ->
http://imagebin.org/293091
[08:51:02] <skunkworks> mach ->
http://imagebin.org/293092
[08:54:58] <quitte> ...and the controller card blinks the lights
[08:55:22] <quitte> mhaberler: thank you a thousand times.
[08:55:27] <mhaberler> sure
[09:00:40] <KGB-linuxcnc> 03Michael Haberler 05stepconf-pncconf-workaround 45cecec 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py 10src/emc/usr_intf/stepconf/stepconf.py stepconf, pncconf: disable check_rt() for now * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=45cecec
[09:01:41] <mhaberler> quitte: you can try this branch - it disables check_rt() in stepconf and pncconf for now (untested). Chrism needs to look at this for a more permanent solution.
[09:09:01] <skunkworks> it is wierd - all the de-accelerations have a little crook in them..
[09:09:53] <skunkworks> (on the 3 higest peaks
[09:10:47] <CaptHindsight> skunkworks: the mach plot has spikes ( mainly negative going) when there's no accel/decell
[09:12:05] <CaptHindsight> the emc velocity plot is also more symmetric
[09:12:07] <skunkworks> there are some durring acc/decel
[09:12:32] <skunkworks> It might just be some sort of problem with the computer I am running mach on..
[09:12:41] <skunkworks> pulses seem to pause for a second I assume
[09:12:50] <skunkworks> us
[09:18:59] <skunkworks> I should boot that same computer with linux.. I wonder if it has sata.
[09:19:31] <skunkworks> right - much more symetrical/smoother. sexy
[09:22:37] <skunkworks> I was wondering why the acc/encoder velocity starts so late.. (it is only the x axis plot... duh)
[10:15:54] <linuxcnc-build> build #40 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/40 blamelist: Michael Haberler <git@mah.priv.at>
[10:15:54] <linuxcnc-build> build #40 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/40 blamelist: Michael Haberler <git@mah.priv.at>
[10:25:23] <linuxcnc-build> build #14 of deb-wheezy-rtpreempt-binary-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-wheezy-rtpreempt-binary-amd64/builds/14 blamelist: Michael Haberler <git@mah.priv.at>
[10:39:29] <linuxcnc-build> build #41 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/41 blamelist: Michael Haberler <git@mah.priv.at>
[10:48:03] <quitte> I got the very same build error as #14
[10:52:06] <linuxcnc-build> build #1374 of deb-precise-sim-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-sim-binary-i386/builds/1374 blamelist: Michael Haberler <git@mah.priv.at>
[10:52:27] <linuxcnc-build> build #1373 of deb-precise-sim-binary-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-sim-binary-amd64/builds/1373 blamelist: Michael Haberler <git@mah.priv.at>
[10:52:44] <linuxcnc-build> build #1368 of deb-lucid-sim-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-sim-binary-i386/builds/1368 blamelist: Michael Haberler <git@mah.priv.at>
[10:53:52] <linuxcnc-build> build #203 of deb-precise-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rt-binary-i386/builds/203 blamelist: Michael Haberler <git@mah.priv.at>
[11:03:30] <linuxcnc-build> build #42 of deb-precise-xenomai-binary-x86 is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-x86/builds/42 blamelist: Michael Haberler <git@mah.priv.at>
[11:10:00] <linuxcnc-build> build #1369 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1369 blamelist: Michael Haberler <git@mah.priv.at>
[11:12:46] <linuxcnc-build> build #1368 of deb-lucid-sim-binary-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-sim-binary-amd64/builds/1368 blamelist: Michael Haberler <git@mah.priv.at>
[11:13:33] <seb_kuzminsky> these build failures are because the stepconf-pncconf-whatever branch isnt based on the latest ubc3 with the fixed deb builds
[11:13:43] <seb_kuzminsky> it's based on some other, divergent version of ubc3
[11:15:07] <KGB-linuxcnc> 03Norbert Schechner 05master 984a58d 06linuxcnc 10share/gscreen/skins/gmoccapy/gmoccapy_handler.py 10share/gscreen/skins/gmoccapy/release_notes.txt gmoccapy_0_9_9_9_9 - pin to modify soft limits * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=984a58d
[11:15:07] <KGB-linuxcnc> 03Norbert Schechner 05master 3ed48a0 06linuxcnc Merge branch 'master' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3ed48a0
[12:06:00] <quitte> http://imgur.com/fE0CiPT the result of applying mhaberler's changes to ubc3
[12:51:10] <skunkworks> same hardware this time..
[12:51:15] <skunkworks> http://imagebin.org/293134
[12:51:24] <skunkworks> http://imagebin.org/293135
[12:51:49] <skunkworks> can you guess? ;)
[12:52:07] <skunkworks> there must be something in the xp causing the spikes.. I would have to try different hardware to test
[12:52:20] <skunkworks> it seems pretty cinistant
[12:52:26] <skunkworks> consistant
[13:00:55] <quitte> seb_kuzminsky: you're doing the packaging? what did you do to get the ppdev module loaded?
[13:12:09] <seb_kuzminsky> hi quitte
[13:12:16] <seb_kuzminsky> i sometimes work on packaging, sure
[13:13:18] <seb_kuzminsky> i'm not sure what ppdev module you're asking about
[13:32:34] <quitte> seb_kuzminsky: the module that make /dev/parport0 available. as opposed to the lp module that is specifically for printers
[13:37:52] <cradek> ppdev is not a part of linuxcnc
[13:40:19] <quitte> true. but for some reason in the ubuntu live cd it just works, while i have to load it manually with a debian system.
[13:41:01] <cradek> that smells like a kernel configuration difference
[13:41:19] <cradek> what kernel package are you using?
[13:43:39] <quitte> cradek the wheezy rt-686-pae kernel. i enabled aufs but it should be 100% identical otherwise
[13:45:08] <cradek> I am not sure what to suggest except compare the pport-related options in the configs
[13:45:40] <quitte> okay. I'll compare the behavior instead
[13:50:47] <quitte> sigh. in ubuntu it's the cups init scripts that load ppdev.
[13:57:39] <cradek> also in wheezy/cups
[13:57:59] <cradek> well not sure if that's the only thing that does it, but I do see it in there.
[14:00:10] <seb_kuzminsky> you can force kernel modules to load by naming them in /etc/modules
[14:00:39] <seb_kuzminsky> or at least you could in... 2005, which is when my server's /etc/modules was last modified
[14:01:12] <cradek> man modules still agrees with you
[14:01:32] <cradek> it seems wrong that this is needed, though
[14:02:01] <seb_kuzminsky> well we dont know what quitte is trying to do
[14:02:07] <cradek> that's true
[14:02:28] <seb_kuzminsky> i dont think he(?) is interested in connecting the parport to linuxcnc via hal, or he'd use 'loadrt hal_parport' in the usual way
[14:03:13] <cradek> ok, I will wait to understand the problem better before offering help(?)
[14:03:32] <cradek> always wise
[15:02:46] <quitte> it's he ;) I guess I'm interested in the usual way
[15:04:30] <quitte> I'm in the process of building a wheezy live system. so far the only modification I did was adding aufs to the preempt_rt kernel. and of course build debian packages of linuxcnc
[15:05:18] <quitte> some error message contained something about insmod. I guess that's when it tried to load ppdev?
[15:07:02] <quitte> the current state is that I can use the machine with my old mill configuration after loading the ppdev module manually
[15:10:07] <quitte> http://pastebin.com/GWieJBGu is where it says that insmod failed
[17:59:43] <KGB-linuxcnc> 03John Morris 05zultron/ubc3-dev e61132e 06linuxcnc 10src/configure.in configure.in: tweak libmodbus not found behavior * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e61132e
[17:59:43] <KGB-linuxcnc> 03John Morris 05zultron/ubc3-dev cfb24f3 06linuxcnc 10src/configure.in configure.in: don't use $TCLCONFIG dirname if $TCLCONFIG is empty * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cfb24f3
[17:59:44] <KGB-linuxcnc> 03John Morris 05zultron/ubc3-dev 17b665d 06linuxcnc 10scripts/linuxcnc.in linuxcnc.in: make race condition less likely by increasing sleep * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=17b665d
[17:59:45] <KGB-linuxcnc> 03John Morris 05zultron/ubc3-dev ff2f7c1 06linuxcnc 10(10 files in 6 dirs) sample-configs in ${datadir}/linuxcnc; rename docsdir to docdir * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ff2f7c1
[17:59:49] <KGB-linuxcnc> 03John Morris 05zultron/ubc3-dev 1c9ecfb 06linuxcnc 10src/module_helper/Submakefile module_helper/Submakefile: create ../libexec in recipe * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1c9ecfb
[19:14:14] <linuxcnc-build> build #41 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/41 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Dave <dave@CalypsoVentures.com>, John Morris <john@zultron.com>
[19:14:29] <linuxcnc-build> build #41 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/41 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Dave <dave@CalypsoVentures.com>, John Morris <john@zultron.com>
[19:20:57] <linuxcnc-build> build #1381 of package-sim-hardy-source is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/package-sim-hardy-source/builds/1381 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Dave <dave@CalypsoVentures.com>, John Morris <john@zultron.com>
[19:26:32] <linuxcnc-build> build #1769 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1769 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Dave <dave@CalypsoVentures.com>, John Morris <john@zultron.com>
[19:36:32] <linuxcnc-build> build #42 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/42 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Dave <dave@CalypsoVentures.com>, John Morris <john@zultron.com>
[20:09:02] <linuxcnc-build> build #1371 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1371 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Dave <dave@CalypsoVentures.com>, John Morris <john@zultron.com>
[20:57:35] <skunkworks_> logger[mah]:
[20:57:35] <logger[mah]> skunkworks_: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-02-14.html
[23:29:58] <zultron> seb_kuzminsky, I can't tell how many of the failed builds are legit on 1c9ecfb088e5.
[23:31:10] <zultron> package-sim-hardy-source is some kind of git tree copy timeout. On package-sim-lucid-source the same step took 17 minutes, but otherwise succeeded.
[23:32:51] <zultron> The deb-precise-rtpreempt-binary-x86 and deb-precise-rtpreempt-binary-amd64 builders errored out with "E: File /home/buildslave/pbuilder-precise-emc2.tgz does not exist"
[23:33:42] <zultron> Those don't sound related to the source, is that correct?
[23:34:36] <zultron> The deb-lucid-rt-binary-i386 failed with "dpkg-shlibdeps: error: no dependency information found for /usr/realtime-2.6.32-122-rtai/lib/liblxrt.so.1 (used by debian/linuxcnc-rtai/usr/lib/linuxcnc/ulapi-rtai-kernel.so)."
[23:35:21] <zultron> That rings a bell, is it related to RTAI's userspace clock routine issue we discussed before?
[23:36:23] <zultron> The deb-precise-xenomai-binary-amd64 builder fails with a bunch of "Cannot mkdir: No space left on device".
[23:37:22] <zultron> These all show up green on my buildbot:
http://junction.ext.zultron.com/grid
[23:39:07] <zultron> I'm going to plop this onto glo/ubc3. If something goes wrong, I'll have to ask forgiveness later.
[23:43:54] <KGB-linuxcnc> 03John Morris 05unified-build-candidate-3 1c9ecfb 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1c9ecfb
[23:51:14] <zultron> ...and *both* our buildbots are rebuilding the exact same code from the exact same commit, just in case the change of branch name introduces a regression.