Back
[02:07:23] <memfrob> skunkworks_, think my board has about 4 of those slots :)
[06:47:34] <jepler> both the "two cards of one type" and "two cards of same type" cases would be interesting to actully test
[06:50:03] <jepler> including if we had two different hal components that both used the rtapi_pci_register_driver APIs
[06:51:38] <jepler> so part of what I discovered last night is that the rtapi_pci.c I originally adapted has two implementations of pci. One for the hostmot2-style which uses the more recent kernel idiom with pci_register_driver and an id_table, and one that uses the old-style pci_get_device, like everything pci but hm2_pci
[06:52:42] <jepler> personally, I'm inclined to not convert those drivers, none of which I can test anyway; if someone wants them to work with rt-preempt / linuxcnc-uspace, they'd have to be not only rtapi-prefixed, but also adapted to use pci_register_driver
[07:52:05] <skunkworks> I swapped the pro/100 and the internal nic. (now the 7i80 is running on the internal nic) and it has been running for an hour without a FE
[07:55:19] <jepler> skunkworks: do you know what chipsets are on each one?
[07:55:53] <jepler> skunkworks: since peter's sending me a 7i80 for development, I am shopping for a second nic this morning. I figured I'd just get one of those intel gigabit cards I use everywhere..
[07:57:30] <jepler> looks like the onboard is Intel Corporation 82567V-2 Gigabit and the card is Intel Corporation 82574L Gigabit
[08:08:01] <skunkworks> well - the pro-100 (I don't have anything newer) on the pci bus seems to not perform as good as the internal nic (this is on 2 systems now)
[08:08:20] <skunkworks> let me look at the chipsets
[08:08:48] <skunkworks> I am seeing about .001ish following error at 1200ipm ;)
[08:09:08] <skunkworks> (spikes - not static error)
[08:12:33] <pcw_home> that represents about 50 usec latency
[08:14:45] <pcw_home> (actual pulse count deviation will be much smaller due to the low gain of the PID loop)
[08:18:05] <skunkworks> this is the current system
http://pastebin.com/Azqs3VDq
[08:19:04] <jepler> to be honest, I'd have guessed the realtek would be the bad nic and the intel would be the good one
[08:19:31] <pcw_home> Yeah the 8111/8169 seems to be the most common NIC by far for low cost MBs
[08:20:19] <jepler> That's what my AMD desktop/server has, and it does work fine for day to day
[08:20:53] <jepler> on the other hand, in the past there have been troubles, and I think people have had trouble with rtai and realtek nics
[08:21:01] <pcw_home> It may be the PCI transfer time/blockage by other I/O that makes the intel slower or higher latency
[08:21:21] <jepler> PCI-E might be a tiny bit better then
[08:21:29] <pcw_home> Yeah i remember the RTK8139s had a huger list of bugs
[08:21:40] <pcw_home> well huge
[08:24:02] <skunkworks> the other system I was testing was a dell system with an intel internal nic.. (and that one worked better than the pci nic)
[08:24:57] <pcw_home> PCIE is more like a network of buffered switches instead of a shared bus
[08:24:58] <pcw_home> so theoretically there less likelyhood of blocking from bus mastering etc
[08:26:08] <pcw_home> (or at least the blockages are closer to the CPU where bandwidth is higher)
[08:37:54] <jepler> anything past ISA is black magic that I'm willing to accept as working..
[08:39:50] <jepler> I went ahead and started a wiki page on uspace.
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Uspace
[08:39:53] <jepler> afk
[08:52:11] <memfrob> what does that page mean by unified?
[08:52:16] <memfrob> (rtapi name)
[08:59:12] <skunkworks> still running - even goes into screen saver
[09:02:02] <skunkworks> I think he is just refering to ubc - unified build canidate..
[09:04:24] <pcw_home> I just turned off my ubc3-7i80 test (to try uspace-hm2-eth)
[09:04:26] <pcw_home> but it ran 70 days at 2 KHz with no issues
[09:06:19] <skunkworks> seems like jeff implimentation should be even better
[09:07:57] <pcw_home> It seems to have a bit lower latency (maybe 1 or20 %) for whatever reason
[09:08:05] <pcw_home> 10 or 20%
[09:09:12] <pcw_home> but i have only run it a few hours so far so that may be just measurement error
[09:10:13] <skunkworks> I think he said there is a little better realtime hardening with it..
[09:14:03] <skunkworks> pcw_home, what are you running it on?
[09:14:09] <skunkworks> (what os)
[09:14:12] <pcw_home> 70 days at 2 KHz is 3.6288e10 packets!
[09:14:24] <skunkworks> wow
[09:15:07] <pcw_home> gigabyte J1800 MB Ubuntu 12.04 Preemt-RT 3.12.16
[09:15:36] <mozmck> can you do something like isocpus with preempt-rt and does it help latency?
[09:15:53] <pcw_home> I think i tried and it made it worse
[09:16:00] <skunkworks> I know idle=poll seems to help just a little
[09:16:17] <jepler> memfrob: whatever the right name is for the machinekit userspace rtapi implementation
[09:16:38] <mozmck> interesting.
[09:17:05] <jepler> mozmck: I haven't tried with isolcpus. It's possible it could make a small difference.
[09:17:07] <skunkworks> it surely helps the rtai.. 30us vs 10us
[09:17:18] <skunkworks> (idle = poll)
[09:18:16] <jepler> hm, looks like I'm using cpu_dma_latency not quite right
[09:18:32] <jepler> I'm not supposed to write the number as ascii ("0\n"), I'm supposed to write it as an integer
[09:18:35] <jepler> wonder if that makes a difference
[09:18:56] <pcw_home> If you use isolcpus you would probably need to set the irq affinities as well
[09:19:04] <mozmck> how would you make the realtime stuff use the isolated core?
[09:19:29] <cradek> jepler: can uspace know whether it is running under an RT-PREEMPT kernel?
[09:19:50] <mozmck> what are irq affinities?
[09:20:06] <cradek> jepler: I ask because it might be nice to avoid the combination of hardware access and no realtime guarantees
[09:20:19] <jepler> cradek: yes, but I don't do that yet.
https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#Runtime_detection_of_an_RT-PREEMPT_Kernel
[09:20:49] <cradek> cool
[09:21:13] <pcw_home> mozmck: which CPU handles which interrupt
[09:21:36] <mozmck> ah, ok thanks.
[09:21:46] <cradek> jepler: I like the wiki page, thanks
[09:21:54] <jepler> mozmck: the processor ID that a task runs on can be set with a call to "pthread_attr_setaffinity_np"
[09:22:29] <mozmck> I see, so it would have to be done in code as well as setting isolcpus
[09:22:51] <jepler> my code right now checks the number of online CPUs and then sets all realtime threads to run only on processor #(nprocs-1)
[09:23:15] <mozmck> does that help latency?
[09:23:16] <jepler> I'm not sure how sysconf(_SC_NPROCESSORS_ONLN) interacts with isolcpus, I'd have to research it
[09:24:04] <jepler> they all run on the same core primarily so that the "rate monotonic scheduling" guarantee can be made
[09:24:51] <jepler> (which says that the slow thread never interrupts the fast thread; running on two CPUs at the same time is equivalent to interrupting)
[09:31:36] <jepler> pcw_home: 3 packets per servo period?
[09:31:56] <jepler> request-read, read-response, write?
[09:32:39] <jepler> cradek: did you look at the new rtapi_pci.cc in any depth? It was getting late by the time I linked to it
[09:32:48] <cradek> no sorry, I went to bed
[09:33:02] <skunkworks> oh the humanity...
[09:34:35] <pcw_home> yes three packets
[09:38:44] <pcw_home> a two packet mode is possible:
[09:38:45] <pcw_home> write packet includes write data, wait-on-DPLL, read and send next read data
[09:38:47] <pcw_home> this has the advantage that the read data can be sent a wire time ahead so theres
[09:38:48] <pcw_home> no time wasted polling for read data
[09:43:03] <pcw_home> but this requires that all read data that may be needed the next cycle is
[09:43:04] <pcw_home> requested each time, basically hardwiring the process data list (no random reads)
[09:43:43] <mozmck> can you have a separate read command for that?
[09:44:24] <jepler> so far one packet has been big enough for everything to read or write?
[09:44:38] <mozmck> In one of my projects I have a command which writes and also is a read command, but another command for read only.
[09:44:58] <jepler> there are certainly conditional writes (index latch)
[09:45:03] <pcw_home> Yes 1500 bytes is plenty
[09:46:37] <pcw_home> yeah but conditional writes could be done away with
[09:47:09] <jepler> a 1500 byte packet at 100 megabit/second is 150us? You don't get many full packets at 2kHz.
[09:48:07] <pcw_home> no but even 128 bytes is pretty big for normal systems
[09:49:27] <jepler> that's true, if epp ever worked then 100Mbit ethernet must be far and away fast enough
[09:49:50] <pcw_home> a 6 axis servo system with say 384 I/O bits will fit in 128 bytes
[10:01:03] <cradek> jepler: that sure looks cleaner, but it's esoteric enough that I don't think I can be a useful reviewer
[10:05:14] <cradek> jepler: in rtapi_request_firmware, if uname fails, uninitialized fd gets used
[10:08:44] <cradek> in rtapi_pci_register_driver, dev is leaked if driver->probe() fails
[10:15:15] <jepler> both those notes added to my TODO list
[10:16:17] <jepler> cradek: I don't have a deep understanding of the pci code either
[10:16:59] <jepler> the short version is that udev can help you iterate over actual devices in the system, and files in /sys can be mmapped to expose the card's mmio regions to userspace
[10:17:52] <cradek> that helps
[10:19:43] <jepler> so for instance, once you establish that you want to talk to this device
[10:19:45] <jepler> 09:47:03 <+cradek> jepler: in rtapi_request_firmware, if uname fails, uninitialized fd gets used
[10:19:55] <jepler> 04:00.0 Bridge: PLX Technology, Inc. PCI9030 32-bit 33MHz PCI <-> IOBus Bridge
[10:20:07] <jepler> and you decide you want mmio region 5, you have to mmap
[10:20:19] <jepler> sys/devices/pci0000:00/0000:00:1e.0/0000:04:00.0/resource5
[10:21:25] <jepler> .. and that's really all there is to it. after that, you just do memory read/write ops on that region of memory
[10:21:59] <jepler> oh I guess you have to enable and disable devices too. that must do .. something
[10:22:02] <jepler> power saving?
[10:36:15] <memfrob> jepler cradek how long have you guys been developing with linux? you guys know a lot.
[10:40:41] <skunkworks> cradek, jepler, usb ports don't work with rtai kernel - do work with the debian -rt kernel...
[10:41:32] <memfrob> skunkworks, the 3.4.55 kernel? i think someone else had the same problem.
[10:41:50] <skunkworks> whatever is on the latest livecd that cradek made..
[10:41:55] <memfrob> ohh.
[10:41:57] <skunkworks> I don't reember
[10:42:09] <skunkworks> I would have to look
[10:42:15] <memfrob> thats not mine then, nvm
[10:42:27] <skunkworks> I think whatever seb was working on
[10:42:43] <skunkworks> it is running the 7i80 with no issues.
[10:44:09] <skunkworks> (the gigabyte J1800)
[10:44:29] <skunkworks> pcw_home, and the vidoe seems decent - glxgears is smooth - (wheezy_
[10:44:40] <jepler> memfrob: I've been using linux since '93, so I've had a few years
[10:45:03] <cradek> skunkworks: could you boot the working kernel, plug and unplug some usb thingy, then pastebin the dmesg, so we can see/guess what drivers it wants?
[10:45:16] <skunkworks> sure
[10:46:13] <cradek> memfrob: I think this was the first Linux system I used:
http://timeguy.com/cradek-files/01188356148/yggdrasil-beta.jpg
[10:46:28] <cradek> I still have the cd (or did a few years ago)
[10:46:49] <memfrob> wow!
[10:47:15] <archivist> yggrasil dates me too but later version
[10:49:52] <skunkworks> cradek,
http://pastebin.ca/2817571
[10:51:00] <cradek> skunkworks: could you include the full boot output please?
[10:51:11] <skunkworks> sure - sorry
[10:59:29] <skunkworks> cradek,
http://pastebin.com/wxcT5RLi
[11:01:22] <skunkworks> (I just switched the hd from the asus motherboard to the gigabit motherboard
[11:04:51] <cradek> but this dmesg is from the hardware that has nonworking usb with seb's kernel?
[11:05:02] <skunkworks> correct
[11:05:17] <skunkworks> do you want a dmesg booting the rtai kernel?
[11:05:31] <cradek> huh, comparing those kernel configs, I don't see any meaningful differences
[11:05:39] <cradek> sure, please
[11:08:18] <cradek> jepler: if rtapi_iounmap does not find the mapping, it goes ahead and munmaps/erases some things anyway
[11:12:49] <skunkworks> cradek,
http://pastebin.com/cxRqKEe2
[11:13:19] <jepler> > [ 17.023978] usb 3-1: device not accepting address 2, error -110
[11:13:29] <jepler> does this happen in both kernels, or just in the broken kernel?
[11:13:46] <cradek> good:
http://pastebin.com/wxcT5RLi bad:
http://pastebin.com/cxRqKEe2
[11:14:22] <cradek> [just in the broken one]
[11:15:28] <jepler> so all the real usb ports are apparently behind this hub that won't enumerate, usb 3-1
[11:16:04] <jepler> since the plugged in devices are at 3-1.4 and 3-1.3.2
[11:20:24] <cradek> USB error -110: USB power exceeded
[11:24:22] <jepler> http://lists.xenproject.org/archives/html/xen-users/2014-03/msg00027.html
[11:24:26] <jepler> they think it has something to do with acpi
[11:24:36] <cradek> you could try setting ehci-hcd's ignore_oc=true
[11:24:45] <cradek> "ignore bogus hardware overcurrent indications"
[11:24:56] <skunkworks> is that a kernel line command?
[11:25:06] <cradek> no, a modprobe parameter
[11:25:27] <jepler> is there a way to set it for the installer?
[11:25:46] <cradek> not sure - test it first
[11:26:24] <cradek> skunkworks: create /etc/modprobe.d/whatever.conf, containing the line: options ehci_hcd ignore_oc=1
[11:27:01] <skunkworks> ok
[11:31:26] <cradek> jepler: and if you follow it, that the acpi problem has something to do with uefi
[11:32:03] <cradek> if this is a uefi problem, shoot me
[11:37:34] <jepler> cradek: sorry, I don't have a gun
[11:38:36] <cradek> ignore_oc also defaults to off, in 3.2.0-4-rt-686-pae
[11:40:56] <cradek> jepler: did you see above about iounmap
[11:42:13] <jepler> cradek: yes
[11:44:22] <skunkworks> assuming I typed it in right - it didn't help
[11:44:29] <skunkworks> still get the 110 errros
[11:44:30] <skunkworks> error
[11:44:36] <skunkworks> and no mouse or keyboard
[11:45:10] <cradek> skunkworks: you can check it with: cat /sys/module/ehci_hcd/parameters/ignore_oc
[11:48:15] <skunkworks> it comes back N
[11:48:29] <cradek> then you haven't done something right, should be Y now
[11:49:08] <cradek> you rebooted after creating it?
[11:49:19] <skunkworks> hmm I double checked the line it is options ehci_hcd ignore_oc=1
[11:49:22] <skunkworks> yes
[11:49:57] <skunkworks> in a file named usboc.conf
[11:50:10] <cradek> hmm
[11:50:12] <cradek> lemme try here
[11:50:14] <skunkworks> in the etc/modprobe.d dirctory
[11:50:16] <skunkworks> directory
[11:52:05] <cradek> does your bios have UEFI/Legacy option?
[11:52:23] <skunkworks> I think so - but I think I tried it both ways. (I can try it again)
[11:52:37] <cradek> hm that modprobe option doesn't work for me either
[11:56:30] <cradek> after adding that file, you have to run dpkg-reconfigure linux-image-3.4-9-rtai-686-pae
[11:57:12] <cradek> and reboot yet again
[11:59:52] <skunkworks> hmm - on a side note.. I have the splash screen running in a o101 repeat [10000] loop... If I hit T while it is running - it runs until the last z move.. (none of the buttons go in)
[12:00:20] <skunkworks> I have to hit the pause button twice to get it to take back off
[12:00:28] <cradek> eww
[12:01:08] <skunkworks> (I am used to ctrl-alt-t bringing up the terminal window.. - and I notice the linuxcnc stopped..)
[12:01:24] <skunkworks> linuxcnc noticed the t
[12:03:50] <jepler> hm, a new pause/step problem? I wonder if it bisects to before or after the new tp
[12:03:54] <jepler> (I mean whether)
[12:04:22] <cradek> skunkworks: is this 2.6 or master?
[12:04:25] <skunkworks> cradek, it is Y now - but no mouse/keyboard
[12:04:27] <skunkworks> master
[12:04:40] <cradek> oh good
[12:04:52] <cradek> let's just all imagine 2.6 works right and not test it
[12:04:58] <cradek> skunkworks: still error -110?
[12:06:11] <skunkworks> let me look
[12:07:11] <skunkworks> so - if you hit the pause button it works as expected.. are you supposed to be able to hit the run next line button? (what T is supposed to do?) because that does nothing..
[12:07:56] <cradek> I don't know what T (step) while running should do
[12:08:02] <cradek> nothing crazy, I guess
[12:08:12] <cradek> probably should finish the current move and then pause
[12:09:32] <skunkworks> still error -110
[12:09:46] <cradek> does it say ehci_hcd ... USB 2.0 started, ... overcurrent ignored
[12:09:52] <cradek> (mine does)
[12:10:27] <jepler> I'm not sure whether the identification of error -110 with overcurrent is right
[12:10:40] <jepler> it's the return value of hub_set_address, which returns negative errno values
[12:10:56] <cradek> oh...
[12:10:59] <jepler> 110 is ETIMEDOUT
[12:11:00] <cradek> google, I trusted you
[12:11:10] <cradek> sigh
[12:11:23] <jepler> which sort of makes sense, as it happens seconds and seconds after it tries to initialize the hub
[12:11:25] <skunkworks> mine says that also..
[12:11:47] <cradek> sorry about the goose chase
[12:12:23] <skunkworks> no problem.. I have seen people say unloading the ehci_hcd module fixes it.. but it didn't for me.
[12:14:20] <cradek> did the older 3.4.55-rtai kernel give working usb on this board?
[12:15:38] <jepler> cradek: let's go find lunch.
[12:15:45] <cradek> mmm lunch
[12:36:07] <memfrob> OC as in overclock?
[12:37:53] <seb_kuzminsky> oc as in over-current protection
[12:39:42] <memfrob> fail..
[12:40:10] <seb_kuzminsky> i'm slowly building your new rtai kernel, i found some bugs with my kernel builder makefile & had to stop & clean that up
[12:40:15] <seb_kuzminsky> maybe i'll get to test it tonight
[12:48:22] <memfrob> the 3.4.96?
[12:49:39] <memfrob> ah right forgot to tell you guys, i have a preempt-rt kernel tree for the cubieboards (sunxi) and ill be writing up a wiki / howto on how to get linuxcnc working on the cubie using debian
[12:53:35] <skunkworks> neat
[12:53:59] <skunkworks> is 3.4.55 what was on the 10.04 livecd?
[12:54:50] <memfrob> no i believe it was 2.6 based
[12:59:00] <seb_kuzminsky> memfrob is right, the 10.04 live cd shipped with 2.6.32 iirc
[12:59:11] <seb_kuzminsky> 3.4.55 was the previous precise rtai kernel i made form shabby's repo
[12:59:33] <skunkworks> ah
[12:59:35] <seb_kuzminsky> then i made 3.4.87, which has problems on dgarr's computer and on one of mine
[12:59:51] <seb_kuzminsky> now i'm making 3.4.96, from a new rtai patch that memfrob made to see if that fixes it
[13:00:39] <skunkworks> sounds great
[13:01:02] <memfrob> im sure it will run fine
[13:01:06] <memfrob> :P
[13:01:23] <skunkworks> seb_kuzminsky, did you see - with the rtai kernel usb's don't work - with the rt-preempt from debian usb's do work
[13:09:28] <skunkworks> jepler, Ummm - so I just noticed that I am running the 7i80 with your ethernet branch - but booted the rtai kernel...
[13:10:25] <jepler> skunkworks: interesting. how's the latency?
[13:11:39] <skunkworks> let me check.. it has been running the splash screen with no FE
[13:13:52] <skunkworks> jepler after a few bit - base thread is aproching 1ms - servo thread around 50us
[13:14:22] <skunkworks> up to 75us
[13:14:38] <skunkworks> how is that even working?
[13:15:38] <skunkworks> seems to be leveling out at 75us/900us
[13:17:49] <pcw_home> may have more sane results if you delete the base thread
[13:18:44] <skunkworks> I am just suprised it is working at all :)
[13:19:21] <skunkworks> a) that it initialized the card correctly and b) loaded linuxcnc and c) ran without following errors..
[13:19:22] <seb_kuzminsky> skunkworks: interesting
[13:19:40] <skunkworks> feature by design?
[13:19:41] <seb_kuzminsky> i've only been listening with half an ear to y'all's debugging
[13:21:06] <micges-dev> weird that there are no overruns
[13:22:03] <skunkworks> overruns are disabled at the moment...
[13:22:18] <skunkworks> so I have been using following error as a sort of test...
[13:22:37] <micges-dev> ah
[13:23:20] <skunkworks> heh - I did a latency-test -h and it errored in terminal and ran with just the servo thread...
[13:37:33] <skunkworks> well - after running for a while (glxgears maximizing and such) I get a bit over 200us on rtai. with -rt I don't see < 35us
[13:37:56] <skunkworks> *latency stays under 35us
[13:41:56] <skunkworks> still interesting that it worked - I would think I would get scolded.
[14:35:48] <jepler> skunkworks: there's not any scolding built in yet
[14:35:58] <skunkworks> heh
[14:36:10] <jepler> though cradek thinks I should add it (specifically, if running on rt-preempt, have hardware drivers refuse to load)
[14:36:16] <jepler> (er, if not running on rt-preempt)
[14:36:34] <jepler> but also I know I need to add some form of overrun detection
[14:36:42] <jepler> I think I can use what rtai does as a guideline
[14:52:40] <cradek> Gene sure thinks the 2.6 kernel hurts his swap. he has said it over and over. I wonder what's really wrong.
[15:21:07] <seb_kuzminsky> new rtai kernel & modules: deb
http://highlab.com/~seb/linuxcnc/rtai-debs precise main
[15:21:10] <seb_kuzminsky> (or wheezy main)
[15:21:31] <seb_kuzminsky> this is memfrob's 3.4.96 kernel patch and the good old modules from the 3.4.55 days
[15:21:42] <cradek> yay
[15:21:49] <seb_kuzminsky> i'm especially curious to see if this fixes dgarr's problem, and mine (when i get home tonight)
[15:22:01] <cradek> and skunkworks's
[15:22:12] <seb_kuzminsky> the usb thing? i haven't thought about that at all
[15:22:38] <seb_kuzminsky> thanks to you guys for working on debugging it while my attention's elsewhere, i appreciate the help
[15:23:09] <seb_kuzminsky> i just got notified by shabby that he re-wrote his rtai master branch again
[15:23:14] <seb_kuzminsky> so i should try that at some point too
[15:25:55] <seb_kuzminsky> last night while waiting for a big build i cloned the xenomai ipipe.git (which is based on the kernel.org linux-stable git and applied the rtai kernel patch as a separate commit on top
[15:26:22] <seb_kuzminsky> i think this will be an easier and/or less error-prone way to maintain the rtai kernel patch
[15:29:22] <memfrob> yay 3.4.96 kernel is up woo!
[15:29:38] <memfrob> thanks seb_kuzminsky!
[15:30:00] <memfrob> seb_kuzminsky, i think the only way to fix the USB issue is to change the kernel config
[15:30:14] <memfrob> (which im perfectly fine doing btw but then you'll need to make new debs)
[15:30:39] <seb_kuzminsky> i dont use the kernel config from the rtai repo any more
[15:30:49] <memfrob> the config i gave you
[15:30:53] <seb_kuzminsky> i'm building the linux-image debs using the debian.org kernel configs
[15:30:58] <memfrob> oh thats why...
[15:31:16] <cradek> memfrob: what setting do you think will fix skunkworks's problem?
[15:31:19] <seb_kuzminsky> with custom configs, but maybe i messed them up
[15:31:40] <memfrob> cradek, well a lot of the debian default configs will conflict with RTAI
[15:31:41] <seb_kuzminsky> cradek: asking the questions that matter, since 1974
[15:32:33] <memfrob> which ones in particular in regards to usb will fix his problem im not sure but im more than happy to provide a config which may fix it
[15:33:02] <memfrob> default options in processor type in features and acpi should be changed for starters
[15:34:38] <memfrob> as for USB, most distros enable really weird stuff by default which i turn off, which ones i dont remember off hand.
[15:35:24] <memfrob> either way seb_kuzminsky will need to make new debs..
[15:36:05] <memfrob> unless of course the version bump magically fixes skunkwork's problem
[15:36:15] <seb_kuzminsky> making debs is time-consuming for my computer but quick for me (except when i find new bugs in my build scripts)
[15:36:37] <memfrob> should i make a config?
[15:37:04] <seb_kuzminsky> it would be most helpful if you could tell us which config settings you think we should change to try to fix the problem
[15:38:05] <memfrob> in that case ill need a copy of the config used in debian
[15:38:35] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/rtai-kernel-configs
[15:46:12] <cradek> seb_kuzminsky: it boots -- building 2.6 for it now
[15:46:25] <seb_kuzminsky> does it run latency-test?
[15:46:37] <cradek> I can try the rtai one
[15:46:50] <seb_kuzminsky> thx
[15:47:30] <seb_kuzminsky> but this is on a machine that had no problems with the 3.4.87 kernel too, right?
[15:47:39] <cradek> yeah
[15:50:19] <cradek> nope, it doesn't run
[15:50:29] <cradek> rtai_hal: disagrees about version of symbol module_layout
[15:50:35] <cradek> latency_rt: [same]
[15:51:22] <cradek> linux-image-* 3.4.96-1linuxcnc; rtai-modules-* 3.9.260.g6394e67
[15:56:28] <cradek> I bet the version number is unchanged, so it didn't upgrade
[15:58:15] <cradek> I think I forced a reinstall from highlab, but it still fails to run rtai's testsuite test
[16:00:37] <cradek> ohhh you built what's actually a downgrade: rtai-modules-3.4-9-rtai-686-pae_3.9.246.g75d17f1_i386.deb
[16:00:49] <cradek> 246 < 260
[16:00:59] <seb_kuzminsky> yeah i rebased
[16:01:02] <seb_kuzminsky> and didnt tell anyone
[16:01:43] <seb_kuzminsky> i've been bouncing around different versions on different branches in the rtai repo like crazy
[16:01:47] <seb_kuzminsky> i'm all dizzy now
[16:01:59] <cradek> after the kernel upgrade and rtai-modules downgrade, it does run
[16:02:04] <seb_kuzminsky> heh
[16:02:22] <seb_kuzminsky> now you just need to sidegrade linuxcnc and retrograde gcc and you should be good
[16:02:43] <cradek> and denigrade seb_kuzminsky
[16:03:03] <seb_kuzminsky> heh
[16:12:32] <cradek> oh aram
[16:43:47] <skunkworks_> logger[psha]_:
[16:43:47] <logger[psha]_> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-07-03.html
[16:45:23] <micges-dev> PCW: did you test mf package yet?
[16:46:14] <PCW> not yet let me try on the 12.04 Preemt RT system now
[16:47:28] <jepler> cradek: do you mean "denigrate"?
[16:54:14] <cradek> yes but the spelling was on purpose...
[16:56:05] <jepler> cradek: changes based on your feedback on rtapi_pci.cc:
http://emergent.unpythonic.net/files/sandbox/0001-fixup-uspace-implementation-of-PCI-APIs.patch
[16:57:57] <PCW> micges-dev: seems to work (tested with 7I76E) what should I test?
[16:57:59] <PCW> (note RPO does not work with the Ethernet cards it reports EPP timeouts)
[16:58:44] <micges-dev> PCW: only if installed binary discover any board
[16:59:08] <micges-dev> PCW: checking that epp bug now
[17:00:05] <PCW> it also says it requires root access for PCI when accessing Ethernet cards
[17:01:28] <micges-dev> I didn't fixed that yet
[17:05:12] <micges-dev> PCW: you must always use --addr for accessing eth boards
[17:05:40] <micges-dev> x@x-desktop:~/PROJECTS/mesaflash3$ sudo ./mesaflash --device 7i76e --addr 192.168.1.121 --rpo 0x100
[17:05:40] <micges-dev> 55AACAFE
[17:06:59] <micges-dev> even without --addr I don't have any epp errors
[17:09:02] <skunkworks_> I was hoping my netgear old usb wireless adaptor would just work (tm) but it doesn't
[17:09:11] <PCW> peter@lcnc:~$ sudo mesaflash --device 7i76e --addr 10.10.10.10 --rpo 0x100
[17:09:13] <PCW> failed to clear EPP Timeout!
[17:09:14] <PCW> EPP timeout on data cycle of read(addr=0x0000, size=4)
[17:09:16] <PCW> failed to clear EPP Timeout!
[17:09:17] <PCW> EPP timeout on data cycle of read(addr=0x0100, size=4)
[17:09:19] <PCW> failed to clear EPP Timeout!
[17:09:20] <PCW> 55AACAFE
[17:10:52] <micges-dev> ok, does you pc have epp on board?
[17:11:34] <PCW> yes it has a parallel port that can do EPP
[17:13:04] <micges-dev> same here
[17:14:12] <micges-dev> ok, found error, in some strange way 10.10.10.10 isn't recognised as a ip address
[17:20:14] <PCW> I would have thought the interface type would be determined by the device
[17:23:07] <micges-dev> yes I'm fixing that now, it is done by scanning all interfaces now but it makes too much problems (like root access while using eth boards)
[17:23:35] <PCW> hmm its always software, i just spent a day trying to debug a UART firmware problem and the bug was in my test code :-(
[17:24:12] <micges-dev> eww
[17:33:07] <memfrob> seb_kuzminsky, i found multiple things that could be cause of skunkworks's issue in regards to USB
[17:36:31] <memfrob> CONFIG_HID_SUPPORT=y CONFIG_HID=m CONFIG_USB_HID=m CONFIG_HID_PID=y CONFIG_USB_DYNAMIC_MINORS=y CONFIG_USB_SUSPEND=y is weird
[17:40:04] <memfrob> build either machine-specific controllers such as EHCI, OHCI, UHCI as built-ins (Y) or if you want it generic, build the entire HID USB system as modules, not half in half out.
[17:41:29] <memfrob> the USB stack in the linux kernel is kind of weird but i had issues in the past when i'd mix the two so depending on my mood i'll either build the entire stack in (Y) or as modules (M) but not 50/50 i get USB descriptor errors and things when i split it like that
[17:41:37] <memfrob> error 55 device unplugged etc.
[17:42:37] <jepler> CONFIG_HID_SUPPORT is a bool. CONFIG_HID_PID is a bool. CONFIG_USB_DYNAMIC_MINORS is a bool. CONFIG_USB_SUSPEND is a bool.
[17:42:55] <jepler> so none of those can be selecte as "m", if I correctly remember the disinction between bool and tristate
[17:44:12] <memfrob> im going to verify that really quick
[17:46:25] <memfrob> hid generic isnt being built at all..
[17:46:34] <memfrob> another problem^
[17:47:37] <memfrob> CONFIG_USB_DEFAULT_PERSIST isnt enabled..
[17:48:59] <memfrob> i actually dont even have CONFIG_HID_SUPPORT in my kernel..
[17:49:21] <memfrob> its not even an option, nor USB_SUSPEND
[17:50:25] <memfrob> invalid config options in config file, not properly updated between kernel versions
[17:51:22] <jepler> (Starting with the 3.10 kernel release, dynamic PM support for USB is
[17:51:23] <jepler> present whenever the kernel was built with CONFIG_PM_RUNTIME enabled.
[17:51:23] <jepler> The CONFIG_USB_SUSPEND option has been eliminated.)
[17:51:43] <jepler> CONFIG_USB_SUSPEND is in Kconfig of seb's 3.4.87 tree
[17:51:55] <memfrob> PM_RUNTIME should be disabled for RTAI
[17:53:12] <memfrob> as should all suboptions in ACPI
[17:55:11] <memfrob> the only feature for RTAI that should be enabled is CONFIG_X86_PM_TIMER
[17:55:24] <memfrob> (under ACPI) ^
[17:57:47] <memfrob> if i had his dmesg output i might be able to help more but a lot of those options should be changed
[17:59:23] <memfrob> CONFIG_DEFAULT_CFQ=y CONFIG_HZ_250=y CONFIG_PREEMPT_VOLUNTARY=y CONFIG_HPET_MMAP=y
[18:00:21] <memfrob> CONFIG_OPTIMIZE_INLINING=y ive seen break things too
[18:03:26] <memfrob> CONFIG_SLAB=y is a no no, CONFIG_DEFAULT_MMAP_MIN_ADDR=65536 should be 4096 err..
[18:06:07] <memfrob> the rtai_32_defconfig is in much better shape from what i see than the other one in that link seb_kuzminsky posted
[18:36:11] <cradek> jepler: those look great
[18:36:29] <cradek> jepler: I will keep trying to go through the rest...
[18:38:44] <cradek> memfrob: from earlier: good:
http://pastebin.com/wxcT5RLi bad:
http://pastebin.com/cxRqKEe2
[18:39:25] <cradek> "good" is the debian -rt kernel
[18:57:55] <memfrob> yes 3.4.87 is the bad one
[18:58:02] <memfrob> 3.4.96 should be the good one
[18:58:06] <memfrob> the new good one i mean
[19:04:21] <jepler> cradek means that one is a debian-built kernel that works for sam, and the other is the rtai-patched kernel that doesn't.
[19:05:45] <memfrob> seb just recently made 3.4.96 debs
[19:15:51] <memfrob> its the same exact IPIPE code from the infamous 3.4.55 kernel
[19:16:59] <memfrob> however the 3.4.96 kernel config has a bunch of stuff in regards to power management that should not be on, therefor probably unstable for some users
[19:49:46] <jepler> fwiw, for 10.04 and possibly for 8.04 we have enabled power management options not encouraged by upstream rtai, because users expect things like the computer to be able to power itself off.
[19:52:21] <memfrob> core ACPI still functions and can power off
[19:52:37] <memfrob> i do it all the time without kernel power management
[19:53:23] <memfrob> i dont fully understand how it works, but it continues working.
[20:15:05] <jepler> seb_kuzminsky, cradek: I've done another rebase, but won't push it just yet in case you guys have any more review comments
[20:16:24] <jepler> the most substantial change is a near-rewrite of rtapi_pci.cc based on actually sitting down and reading it .. plus cradek's helpful reviews
[20:19:04] <jepler> here's the diff between my current branch and the branch on git.lo:
http://emergent.unpythonic.net/files/sandbox/rtos-uspace-apis-updates.patch
[20:19:31] <jepler> (some whitespace-only changes excluded; I did a "git rebase --whitespace=fix", which does things like strip trailing whitespace on lines I touched anyway)
[20:19:51] <jepler> (excluded automatically, by 'git diff -b')
[20:53:26] <cradek> jepler: I don't mind a rebase. I am not in the middle of anything.
[20:56:16] <jepler> seb_kuzminsky: if you don't NAK another rebase shortly, I'll go ahead and push this rebase of all 3 of my dependent branches
[20:57:07] <jepler> When it comes to merging with master, I wonder whether to go in one step or in two
[20:57:24] <jepler> I particularly hoped seb would review and maybe try the pci / hm2 portions
[20:57:34] <cradek> well he's utterly swamped
[20:57:40] <jepler> I know
[20:57:55] <cradek> you and I can try it on some hardware here...
[20:58:05] <jepler> the code can live in a branch for awhile longer too
[20:58:34] <cradek> true, but not too long if it feels done
[20:59:34] <jepler> I do have a few things that are on my todo list and not in the branch yet
[20:59:38] <jepler> realtime delay checks
[20:59:40] <jepler> "supports realtime deadlines" vs "hardware access" vs "runs in kernel space" in halmodule / APIs
[20:59:43] <jepler> don't run hardware if not rt-preempt?
[21:00:10] <jepler> hmm and somewhere I lost the item that said to look at in-tree documentation and update it
[23:10:54] <skunkworks_> i wonder if there is any downside to putting idle=poll in the kernel line by default.. It always makes the latency better.. (for me anyway)
[23:11:43] <skunkworks_> the 2 systems I was testing today - 35us down to 10us.. the rt-preempt - 55us down to 35us..
[23:12:32] <skunkworks_> I thought it only worked good for amd systems - but it also helps the intel board.
[23:14:35] <skunkworks_> found this tidbit. idle=poll is a real power hog. It will disable C1/C1E, which will remove the final remaining bit of latency at the expense of a lot more power consumption, so use that one only when it's really necessary. For most this will be overkill, since the C1* latency is not all that large.
[23:14:56] <skunkworks_> I remember reading that you want to make sure you have enough cooling if you do idle=poll.
