Back
[02:41:58] <seb_kuzminsky> ok, a clean set of linux/rtai debs is up in the usual place:
[02:42:30] <seb_kuzminsky> deb
http://highlab.com/~seb/linuxcnc/rtai-debs (wheezy|precise) main
[02:42:41] <seb_kuzminsky> the linux-image version is 3.4.55-2linuxcnc
[02:43:15] <h_maximilian> Good morning Seb
[02:43:38] <h_maximilian> are you in a European tz or are you up late ?
[02:43:52] <seb_kuzminsky> the rtai-modules version is unfortunately still 3.9.260.gsomething
[02:44:04] <h_maximilian> I did not continue last night with my gantry setup, will do so now.
[02:44:23] <seb_kuzminsky> i've run these debs on a wheezy vm (success) and on a precise baremetal machine (success, was flaky with 3.4.87 and .96)
[02:44:57] <seb_kuzminsky> these are my release candidates, please take them for a whirl and let me know if there's anything amiss
[02:45:13] <h_maximilian> Question: I noticed that the rtai kernel is compiled without magic sysrq support. Is that by design, or does nobody else need it ? Or does it hurt the rt.
[02:45:31] <seb_kuzminsky> hi h_maximilian! i'm in MDT (UTC-6)
[02:46:06] <h_maximilian> I am in CET
[02:46:20] <h_maximilian> so you are either up earlier or up very late ;)
[02:46:45] <seb_kuzminsky> h_maximilian: you must be using an older rtai kernel, the one i just build has sysrq:
[02:46:49] <seb_kuzminsky> CONFIG_MAGIC_SYSRQ=y
[02:48:41] <h_maximilian> ah, great, thanks. I found that magic sysrq quite helpfull whenever something went wrong.
[02:48:51] <seb_kuzminsky> yeah it's handy
[02:49:03] <seb_kuzminsky> good luck with your gantry, i'm about to go to bed :-)
[02:49:53] <h_maximilian> thanks. Good rest then :)
[05:19:07] <micges-dev1> 3
[05:19:07] <micges-dev1> 3
[06:03:11] <h_maximilian> Hi
[06:04:20] <h_maximilian> whenever I have G61 or G61.1 in my ngc file the gantry just makes a big jump on the two x axes and hits a following error. No problem if I use G64.
[06:04:36] <h_maximilian> like g64p0
[06:04:52] <h_maximilian> does anybody have an idea what could cause this ?
[08:34:45] <skunkworks> The latest kernel - usb still don;t work. I could try 10.04 and see if usb's work.
[08:34:55] <skunkworks> so far the usb's only work on the -rt kernel
[08:55:25] <cradek> skunkworks: is this latest one you tried 3.4.55-2linuxcnc
[08:55:35] <skunkworks> yes
[08:55:43] <skunkworks> downloaded this morning
[08:55:53] <cradek> darnit
[08:56:41] <skunkworks> they might not have worked with 10.04 - I don't remember. (new hardware.. - don't remember what I have tested)
[08:58:12] <seb_kuzminsky> i dont care that much how 10.04 did on that hardware, is debian's 3.2 works then our 3.4 should too
[08:58:54] <seb_kuzminsky> skunkworks: can you email or pastebin the output of lspci
[08:59:12] <skunkworks> sure - give me a second.
[09:02:02] <seb_kuzminsky> and do you know which usb drivers get loaded when 3.2-rt boots
[09:06:40] <skunkworks> seb_kuzminsky,
http://pastebin.ca/2818994
[09:08:59] <skunkworks> seb_kuzminsky,
http://pastebin.ca/2818996
[09:12:35] <skunkworks> let me boot the -rt
[09:18:55] <dgarr> seb_kuzminsky: today's test with new 3.4.55-2linuxcnc
http://www.panix.com/~dgarrett/stuff/09jul14_a.txt
[09:24:41] <cradek> well that stinks
[09:25:09] <seb_kuzminsky> thanks skunkworks & dgarr
[09:30:31] <cradek> 17.055515] usb 3-1: device not accepting address 2, error -110
[09:30:36] <cradek> same thing
[09:30:54] <skunkworks> right
[09:31:13] <jepler> micges-dev1: dunno if you read the log, but I did find a 64-bit bug in hm2-eth and fixed it in the jepler/rtos-uspace-hm2-eth branch.
[09:34:07] <seb_kuzminsky> [ 1.202854] ehci_hcd 0000:00:1d.0: cache line size of 64 is not supported
[09:34:30] <cradek> do you think that's an error?
[09:34:35] <seb_kuzminsky> dont know
[09:37:34] <seb_kuzminsky> skunkworks: would you try adding "pci=noacpi" and "acpi=off" to your kernel command line?
[09:37:59] <skunkworks> sure
[09:38:43] <seb_kuzminsky> this person had the same problem (and another one which you dont have) and fixed it with those kcli args:
http://forums.debian.net/viewtopic.php?f=7&t=110182
[09:39:00] <seb_kuzminsky> bbl
[09:39:04] <seb_kuzminsky> thanks for all your testing
[09:39:47] <jepler> I've only tested two machines. one (core2) works fine, the other (amd sempron 64) doesn't boot from usb, and I was too tired to try the boot media thing
[09:40:16] <jepler> that latter computer is ca 9 years old
[09:42:14] <skunkworks> seb_kuzminsky, no go...
[09:54:25] <micges-dev> jepler: yes I saw it, thanks
[10:22:38] <cradek> fwiw, new live image at
http://www.linuxcnc.org/binary.hybrid.iso containing 3.4.55-2linuxcnc and rtai, but not a linuxcnc package; md5sum is 3cc2ce...
[10:32:04] <CaptHindsight> I'll give that a try in about 3 hours
[10:34:03] <seb_kuzminsky> it's probably time to switch the precise & wheezy buildslaves to 3.4.55-2linuxcnc
[10:34:20] <seb_kuzminsky> then we have to switch all our early-adopter users to the new kernel too
[10:35:09] <cradek> although 3.4.55-2linuxcnc doesn't fix dgarr's or skunkworks's problems, it does fix yours, right?
[10:41:54] <cradek> hmm, does anyone know enough apt to say how to divert gksu to actually be gksudo?
[10:42:18] <cradek> if so, then I could have a working update-manager
[10:44:00] <seb_kuzminsky> yes, 3.4.55-2linuxcnc runs without flaw on my machine that was flaky with the other (non-.55) kernels
[10:44:20] <seb_kuzminsky> it runs rtai's latency-test and linuxcnc 2.6 without any issues, and the usb wifi works
[10:45:00] <seb_kuzminsky> i bet there is some kernel config things that changed between 3.2 (works for skunkworks) and 3.4 (doesn't work for skunkworks) that i have not accounted for
[10:45:36] <seb_kuzminsky> i'm using the .config from debian's linux-image-3.2 packages, with a pass through "make oldconfig", i bet that's not good enough
[10:45:53] <seb_kuzminsky> i'm diffing the .configs to see if anything sticks out
[11:16:37] <seb_kuzminsky> skunkworks: i see from your lspci that you have both an ehci (usb 2.0) and xhci (usb 3.0) controller on your computer
[11:16:53] <seb_kuzminsky> and it's the ehci controller that complains about cache line size (not sure if that's relevant) and that fails to enumerate your devices
[11:17:16] <seb_kuzminsky> can you try plugging them in to your xhci (usb 3.0) controller instead? (with the 3.4.55-2linuxcnc rtai kernel)
[11:28:46] <skunkworks> all usb's don't work. (even plugged into the motherboard headers)
[11:33:45] <seb_kuzminsky> aha, bummer :-(
[11:38:09] <seb_kuzminsky> http://www.linux-usb.org/FAQ.html#ts6
[11:38:09] <skunkworks> thanks for looking at this. my internet foo isn't helping at all
[11:39:13] <skunkworks> with nothing plugged in I get those -110 errors in dmesg
[11:40:21] <seb_kuzminsky> there is probably some usb device on-board that is not accepting its address and complaining in the dmesg
[11:40:22] <skunkworks> I could check for a bios update.. I updated it when I got it a few months ago
[11:40:38] <seb_kuzminsky> couldnt hurt (well i guess it could)
[11:40:51] <skunkworks> heh
[11:41:09] <seb_kuzminsky> i'd like to see dmesg frmo the working -rt kernel showing usb setup
[11:41:14] <seb_kuzminsky> and lsusb from both
[11:41:20] <skunkworks> shoot - sorry - I can do that
[11:42:30] <seb_kuzminsky> also, some dude on the internet suggests that 'rmmod ehci-hcd', to force it back to usb 1.1 mode, helped him
[11:43:58] <skunkworks> I tried that also :)
[11:44:20] <seb_kuzminsky> ah
[11:44:32] <seb_kuzminsky> are you using an external 8-port usb hub?
[11:44:54] <cradek> I think the thing that doesn't accept its address is the "hub" which is all the onboard ports
[11:45:12] <skunkworks> what is the wheezy version of rmmod?
[11:45:17] <seb_kuzminsky> [ 53.748730] hub 3-0:1.0: unable to enumerate USB device on port 1
[11:45:41] <seb_kuzminsky> i think the hub is talking but the thing plugged in to the hub is not talking
[11:45:52] * seb_kuzminsky <--- guessing
[11:46:03] <skunkworks> ok - sudo rmmod worked.. (but didn't make the usb work..)
[11:46:23] <seb_kuzminsky> skunkworks: wheezy's rmmod is from kmod 9
[11:46:53] <seb_kuzminsky> can you pastebin a dmesg of a usb insertion after the rmmod
[11:46:57] <seb_kuzminsky> ?
[11:47:09] <awallin> hi all, I'm hoping to pick up my cutting simulation work in the next few weeks...
[11:47:41] <cradek> that's excellent
[11:47:50] <cradek> we all want that!
[11:48:04] <skunkworks> seb_kuzminsky, I will try again - but I don't think anything happens in dmesg with pugging/unplugging a usb device
[11:48:19] <seb_kuzminsky> skunkworks: hm, weird
[11:48:28] <seb_kuzminsky> awallin: sweet :-)
[11:49:03] <seb_kuzminsky> skunkworks: also, 'lsusb -t' shows a tree view of your usb busses, which would be helpful in figuring out where in the chain the problem is
[11:49:20] <awallin> I'm probably going to need some help interfacing with the linuxcnc interpreter at some point - I have an old hack by mpictor working I think, but it's quite ugly
[11:50:23] <seb_kuzminsky> awallin: feel free to ask here or on the emc-developers list any time
[11:51:34] <awallin> seb_kuzminsky: ok, I will :) It'll take a moment to get this new scheme going at the "hello world" level first..
[11:52:18] <awallin> the paper I am looking at lately is this:
http://www.merl.com/publications/docs/TR2012-025.pdf
[11:56:32] <seb_kuzminsky> skunkworks: flipping a magic bios option fixed it for this guy:
http://ubuntuforums.org/showthread.php?t=1932824&p=11729941#post11729941
[12:04:45] <skunkworks> seb_kuzminsky, working -rt usb's
http://pastebin.ca/2819028 http://pastebin.com/gUNL0U46
[12:04:51] <skunkworks> lsusb? what package is that?
[12:24:50] <seb_kuzminsky> usbutils
[12:35:23] <skunkworks> seb_kuzminsky, working -rt
http://pastebin.com/KNbyhDjV
[12:35:30] <skunkworks> rebooting
[12:39:07] <skunkworks> seb_kuzminsky, non working
http://pastebin.com/0TCbPyvH
[12:41:15] <skunkworks> there is a bios update
[12:58:21] <skunkworks> bios didn't help
[13:00:09] <pcw_home> are there any BIOS USB options to play with?
[13:00:24] <skunkworks> a ton. But have not found anything to help
[13:00:39] <skunkworks> pcw_home, don't you have one of these motherboards?
[13:01:05] <pcw_home> Yes i do
[13:01:06] <skunkworks> GA-J1800N-D2H
[13:02:01] <skunkworks> have you tried any of the rtai kernels with usb?
[13:02:24] <skunkworks> the -rt works just fine
[13:02:25] <pcw_home> the old 2.6.122 one works
[13:02:41] <cradek> ooooh there's a gconf key that fixes it
[13:03:26] <skunkworks> pcw_home, 10.04
[13:03:29] <skunkworks> ?
[13:04:02] <pcw_home> Maybe 12.04 with 2.6.122 RTAI
[13:04:57] <pcw_home> its been several months but I can try again
[13:07:53] <skunkworks> I have a hd with 10.04 and 2.6.122 - usb's don't work either
[13:07:58] <skunkworks> (just tested)
[13:08:36] <pcw_home> I would have noticed if it did not work (KB and mouse both USB)
[13:09:34] <pcw_home> that how I got the RTAI latency numbers
[13:09:36] <pcw_home> but pretty sure its was 12.04 with a 2.6.122 RTAI kernel
[13:10:09] <pcw_home> I'll try again when I get in
[13:10:34] <seb_kuzminsky> skunkworks: are you using an external hub?
[13:10:56] <skunkworks> no
[13:11:17] <skunkworks> and I don't see anything in the bios about booting 'other' os
[13:11:25] <seb_kuzminsky> are you, pcw_home ?
[13:13:07] <seb_kuzminsky> i wonder why that mobo works for pcw with 2.6.32 but not for skunkworks
[13:14:28] <cradek> ooooh I can have it do an upgrade after install, so people will automatically get the latest released version (if they're online when they install)
[13:15:26] <skunkworks> https://plus.google.com/photos/yourphotos?banner=pwa&pid=6034121690017994546&oid=101125245752137353135
[13:16:20] <skunkworks> https://plus.google.com/photos/yourphotos?banner=pwa&pid=6034121827512195762&oid=101125245752137353135
[13:16:53] <skunkworks> sorry
[13:17:07] <cradek> Sign in to continue to Google+
[13:17:14] <skunkworks> sorry
[13:17:57] <pcw_home> I'll try 2.6.32 again in a bit
[13:21:44] <cradek> oh good effing grief
[13:22:42] <cradek> gconftool-2 (a utility to write an entry in an overly-complicated config file tree in some unnecessary-bs xml format) fails because $DISPLAY is not set so it can't launch a dbus-daemon, whatever that is
[13:23:37] <skunkworks> https://picasaweb.google.com/101125245752137353135/Random?feat=directlink
[13:23:40] <skunkworks> does that work?
[13:23:49] <cradek> [rtfm...] oh maybe --direct will work
[13:24:09] <cradek> skunkworks: yep
[13:24:45] <cradek> skunkworks: wow look at all the choices you have
[13:24:57] <skunkworks> I think I have fiddled with all of them...
[13:31:13] <seb_kuzminsky> except the one pcw_home fiddled with
[13:35:28] <skunkworks> what?
[13:35:40] <skunkworks> oh
[13:35:42] <skunkworks> :)
[13:35:51] <skunkworks> what is 2.6.32?
[13:36:56] <pcw_home> whatever the livecd RTAI kernel version is
[13:38:32] <skunkworks> ah
[13:52:21] <micges-dev> 9+9+9,
[13:52:33] <micges-dev> ,,020,00418000000000009*
[13:53:35] <micges-dev> ^^sorry, little hacker session
[13:56:16] <seb_kuzminsky> http://www.smbc-comics.com/?id=2999
[13:58:13] <jepler> pcw_home: repeating myself one last time, I found and fixed a 64-bit hm2-eth bug. now it works.
[13:58:56] <micges-dev> seb_kuzminsky: haha
[13:59:59] <pcw_home> Great (and glad its not some other weird machine specific oddness)
[14:01:55] <pcw_home> I ran uspace-hm2-eth over the weekend at 2KHz on the J1800-DH2 and had no issues
[14:02:45] <jepler> nice
[14:02:53] <jepler> I think skunkworks has had something running for days too
[14:04:12] <pcw_home> I only stopped it to try the 7I80-16 GPIO
[14:04:36] <jepler> I'd have saved an hour of debugging if I'd believed I hadn't transcribed that first network transaction wrong
[14:04:45] <skunkworks> I just took it down the morning - so a few days. (at 1khz)
[14:04:51] <cradek> aha, I got update-notifier to work
[14:04:52] <jepler> since the bug was simply causing 4 zero bytes to be spuriously inserted
[14:05:03] <pcw_home> so it was busted (too many bytes)
[14:05:18] <cradek> now I just need to turn off the "Notify me of a new Ubuntu [sic] version:" thing
[14:05:26] <jepler> right, so that's how gpio.000.out turned on the led for gpio 24
[14:08:31] <pcw_home> the packet parser believes any kind of crap you throw at it until the first detected error
[14:08:33] <pcw_home> maybe the writes should increment a write success counter to verify that write succeeded
[14:10:01] <jepler> those last 4 bytes would be interpreted as the start of a new command, right?
[14:10:14] <jepler> I'd have to read the docs to see how 00 00 would be interpreted in the protocol
[14:10:41] <pcw_home> Yeah but 0 is not a valid command so it should have caused a parse error (and red light)
[14:11:21] <jepler> there may well have been an error light I didn't look at or understand
[14:12:14] <pcw_home> I can try by hand, if it doesn't raise a parser error it certainly should
[14:23:27] <pcw_home> Yes:
[14:23:29] <pcw_home> >83c20411ffffffffffffffffffffffff01420001
[14:23:30] <pcw_home> > fecaaa55
[14:23:32] <pcw_home> but:
[14:23:33] <pcw_home> >83c20411ffffffffffffffffffffffff000001420001
[14:23:35] <pcw_home> No answer
[14:23:36] <pcw_home> and red fault light illuminates
[14:24:47] <jepler> so also too bad I didn't go looking at the LEDs
[14:26:30] <Tom_itx> damn. had been having network issues with 10.04. had tried the live cd, SSD and regular HDD with no luck
[14:26:44] <Tom_itx> loaded the live cd again today and it connected right away
[14:26:51] <cradek> turning off "Notify me of a new Ubuntu [sic] version" does not stick, but who knows if it does anything, anyway
[14:37:13] <pcw_home> the hm2-eth driver should probably poll the status register to check for errors
[14:44:51] <seb_kuzminsky> skunkworks: if you update you'll get 3.4.55-3linuxcnc, i changed some usb config setting, maybe it helps your machine?
[14:48:12] <cradek> ooh look, updates are available
[14:49:15] <seb_kuzminsky> cradek: and it's not even a downgrade this time
[14:49:29] <cradek> yay
[14:49:37] <cradek> you're good as long as you don't run out of positive integers
[14:50:43] <cradek> "restart required" because of the kernel update, even though it was our kernel
[14:50:46] <cradek> so, that's nice
[14:52:43] <cradek> rtai still works, yay
[14:53:31] <cradek> my usb still works
[15:35:20] <skunkworks_> logger[psha]:
[15:35:20] <logger[psha]> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-07-09.html
[15:37:20] <skunkworks_> seb_kuzminsky: ok - won't be able to test until tomorrow
[15:42:24] <seb_kuzminsky> skunkworks_: no problem
[15:46:11] <seb_kuzminsky> cradek 3.4.55-3linuxcnc is the exact same linux & rtai code as -2linuxcnc, but with a couple of extra config options enabled
[15:46:20] <cradek> cool
[15:46:39] <cradek> oh my, zsync is awesome
[15:46:39] <seb_kuzminsky> i dont have any high hopes that it'll fix skunkworks_ 's problem, it's a shot in the dark :-(
[15:46:47] * seb_kuzminsky google zsync
[15:46:53] <cradek> it synced the new iso, downloading only 93 MB
[15:46:58] <cradek> how is that even possible
[15:47:41] <seb_kuzminsky> wow, that's cool
[15:47:52] <cradek> it knows all about gzip
[15:47:59] <cradek> it must know about a lot of things to pull that off
[15:48:15] <seb_kuzminsky> "client-side rsync" violates my understanding of rsync
[15:49:44] <cradek> I put the zsync file on wlo - try it if you have an old iso
[15:50:11] <cradek> cd ~/directory-with-old-iso; zsync
http://www.linuxcnc.org/binary.hybrid.iso.zsync
[15:50:48] <seb_kuzminsky> ah, server-provided metadata, that makes sense
[16:01:11] <jepler> cradek: wow indeed
[16:04:13] <cradek> that will probably put my "build and share a new iso" down around 20 minutes
[16:07:34] <cradek> Failed to execute child. [OK]
[16:07:59] <cradek> that might be a surprising error dialog, to some.
[16:10:49] <skunkworks_> I thought we just send them back to mexico..
[16:11:36] <jepler> skunkworks_: ow ow ow
[16:12:54] <cradek> 3.4.55-3linuxcnc test iso available at the usual url - I recommend using zsync to get it
[16:13:45] <cradek> now with update-manager
[16:14:12] <cradek> (I hope I can get out of the distro-making market soon)
[16:17:53] <skunkworks_> heh - cradek your stuck with it...
[16:21:40] <skunkworks_> cradek: thanks for all the work on the iso. it was love overdue.
[16:21:44] <skunkworks_> or long...
[16:25:41] <skunkworks_> hmm - no wine in the house..
[16:26:12] <seb_kuzminsky> zsync some from cradek
[16:27:47] <skunkworks_> hmm - does that work?
[16:28:47] <skunkworks_> breaking out the hard liquor is probably not a good idea this early
[16:31:19] <cradek> I guess wine is not my idea of hard liquor...
[16:31:34] <skunkworks_> heh
[16:32:01] <skunkworks_> (I have no wine - so was thinking about brandy or rum...)
[16:33:53] <skunkworks_> jepler: doing a performace test on those drive boxes using the gnome-disks-manager or whateve it is called... gets about 70MBs write 360MBs read.
[16:34:07] <skunkworks_> MB/s
[16:34:42] <skunkworks_> which makes more sense to me..
[16:35:18] <seb_kuzminsky> skunkworks_: i see from your "working lsusb" that you have two hubs plugged in, and i see from the rtai kernel dmesg that it's complaining about an overcurrent condition
[16:35:33] <seb_kuzminsky> can you try just one device plugged directly into the computer, with no hubs or anything else to draw current?
[16:35:41] <seb_kuzminsky> (just trying to triangulate the problem)
[16:36:24] <cradek> seb_kuzminsky: I think that is not really an overcurrent error. jepler looked at the source and concluded the internets are wrong about that.
[16:37:14] <skunkworks_> seb_kuzminsky: I can test some more... (although - if I don't have anything usb plugged in - I still get the -110 errors)
[16:37:22] <seb_kuzminsky> this error is in error? [ 1.214627] ehci_hcd 0000:00:1d.0: USB 2.0 started, EHCI 1.00, overcurrent ignored
[16:38:04] <cradek> "overcurrent ignored" is the result of a module option we added to try to fix the error -110, which we mistakenly thought was an overcurrent detection
[16:38:08] <seb_kuzminsky> skunkworks_: oh, hm, maybe i'm barking up the wrong tree then
[16:38:36] <cradek> ... because I used the internets carelessly to determine that -110 meant overcurrent, which it doesn't really
[16:40:24] <skunkworks_> I love cooking with red palm oil.. it is like axle greese
[16:58:53] <mozmck> axle grease might be cheaper then...