Back
[00:00:43] -!- lyzidiamond has quit [Remote host closed the connection]
[00:00:56] -!- Nick001-shop has quit [Quit: ChatZilla 0.9.90.1 [Firefox 29.0.1/20140506152807]]
[00:07:51] -!- lyzidiamond has quit [Ping timeout: 248 seconds]
[00:09:06] -!- patricka_ has quit [Remote host closed the connection]
[00:15:38] -!- aniM has quit [Ping timeout: 252 seconds]
[00:16:40] <micges-dev> cradek: beta mesaflash package:
http://filebin.ca/1Rxhp8K6nTT4/mesaflash_3.0.0_i386.deb
[00:19:10] -!- The_Ball has quit [Remote host closed the connection]
[00:22:34] -!- asdfasd has quit [Ping timeout: 264 seconds]
[00:24:51] <jepler> cradek: it's permitted in posix shell, look at the production case_item_ns in
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
[00:25:01] <jepler> cradek: and it fixed my editor being bitchy about paren-matching in this case
[00:25:22] <jepler> cradek: so I could drop it, or split it to a separate commit
[00:25:26] <jepler> preference?
[00:29:43] -!- zee-Lathe has quit [Ping timeout: 248 seconds]
[00:31:27] -!- tinkerer has quit [Quit: Leaving.]
[00:48:19] -!- sumpfralle has quit [Ping timeout: 272 seconds]
[01:23:10] -!- aniM has quit [Ping timeout: 264 seconds]
[01:28:16] -!- K6MLE has quit [Ping timeout: 246 seconds]
[01:36:15] <cradek> no strong preference
[01:37:14] <cradek> I'm offended that it was to satisfy an editor's substandard understanding of sh, but that's no reason to undo it if it's equally valid
[01:40:58] -!- jerryitt has quit [Quit: Connection closed for inactivity]
[01:41:34] <jepler> vim certainly doesn't get it right in this case
[01:44:46] <cradek> jepler: in 39354653, the setfsuid seems like it must be important, but I don't immediately see the idea behind it. is it because rtapi_app is sometimes installed setuid now?
[01:45:36] <cradek> is it supposed to make the core dumps safer?
[01:54:32] <cradek> - chan->params->u32_param = 0xF;
[01:54:33] <cradek> + chan->params->rtapi_u32_param = 0xF;
[01:54:46] <cradek> harmless but probably not intended?
[01:55:30] <jepler> cradek: yes, that was a search-and-replace error not caught.
[01:56:49] <jepler> cradek: yes, as soon as possible in rtapi_app we want to start doing I/O as ourselves, with a few exceptions
[01:57:41] <jepler> cradek: see 94f429bf, which maybe should be squashed, for an example
[01:58:03] <jepler> same at ed77f61a
[01:58:15] <jepler> need root permissions to open device stuff
[01:59:02] <jepler> .. but setfsuid() doesn't apply to shm API calls, so I have to use a different method to ensure the shm is owned by the user (in 39354653)
[01:59:15] -!- andypugh has quit [Quit: andypugh]
[02:00:09] <jepler> I use the counted method in the pci code because I was too tired to see whether anything there was calling another place where I wanted to have root filesystem I/O
[02:02:10] <jepler> + /* UIO-pci-generic should bind to the device now. Wait to avoid races. */
[02:02:13] <jepler> wtf is that
[02:02:48] -!- Einar1 has quit [Quit: Leaving.]
[02:04:23] <cradek> //FIXME: Support more than one card!
[02:04:24] <cradek> hmm
[02:05:43] <jepler> I haven't understood this code well enough to know whether limitations like that are easy or hard to lift..
[02:08:09] Guest3672 is now known as abetusk
[02:10:17] <jepler> I don't even have /sys/bus/pci/drivers/uio_pci_generic
[02:11:16] z_ is now known as Guest22237
[02:12:24] -!- zeitue has quit [Read error: No route to host]
[02:18:02] <jepler> soooo .. it turns out there are two implementations of userspace pci
[02:18:06] <jepler> *bodypalm*
[02:18:57] <jepler> one set of APIs which use rtapi_pcidev and one set which use rtapi_pci_driver (which was possibly pci_driver upstream at machinekit)
[02:21:47] <jepler> so there are 350 lines of rtapi_pci.cc that can just be deleted :-/
[02:21:49] <jepler> and hm2 still runs
[02:22:02] <jepler> hm2-pci
[02:22:11] <jepler> so this pretty much shows that I need to beat on rtapi_pci.cc until it doesn't suck
[02:23:56] -!- patrickarlt has quit [Remote host closed the connection]
[02:29:03] -!- patrickarlt has quit [Ping timeout: 240 seconds]
[02:34:05] -!- aniM has quit [Ping timeout: 272 seconds]
[02:34:13] prtksxna is now known as zz_prtksxna
[02:35:33] <jepler> if (mmio == NULL)
[02:35:33] <jepler> munmap(mmio, rtapi_pci_resource_len(dev,bar));
[02:43:35] -!- AR__ has quit [Ping timeout: 272 seconds]
[02:44:06] amnesic is now known as amnesic_away
[02:54:32] <skunkworks_> how does the realtime delay work for just the servo thread? does it just get triggered if the processes within the thread take longer than the servo thread? or is it takes longer than a percentage of the servo thread?
[02:54:48] <skunkworks_> servo period
[02:55:40] -!- amiri has quit [Remote host closed the connection]
[02:56:20] <jepler> in rtai rtapi, there are two distinct checks. The first (and newest) is the return value from rt_task_wait_period(), an RTAI API. If it returns RTE_TMROVRN then we diagnose an 'unexpected realtime delay on task'
[02:56:29] <jepler> I don't know what it does inside, but I could go learn
[02:57:57] <jepler> the second, and older, is the servo one. It is just a heuristic: it measures the number of CPU cycles from the start of one call to the motion handler to the start of the next one. If the newest interval is more than 1.2x as many cycles as any of the others, then it diagnoses "Unexpected realtime delay", with information about the number of cycles
[02:58:11] <jepler> the first one is diabled for uspace because uspace doesn't use rt_task_wait_period, it uses some other call (clock_nanosleep)
[02:58:42] <jepler> and the second is disabled (A) simply because it was always disabled for sim and (B) because it gives false positives when CPU frequency scaling is enabled, which may be the case in -rt kernels I think
[02:59:02] <skunkworks_> interesting
[02:59:35] -!- patrickarlt has quit [Ping timeout: 248 seconds]
[03:01:02] <skunkworks_> so both have to be rewritten - and it sounds like only the first one (which has to be reworked to use clock_nanosleep) is usable
[03:01:21] -!- patricka_ has quit [Ping timeout: 255 seconds]
[03:01:24] zz_prtksxna is now known as prtksxna
[03:01:26] -!- prtksxna has quit [Excess Flood]
[03:01:52] <jepler> yeah, some form of "unexpected realtime delay" would *cough* be nice
[03:02:27] <jepler> cradek: OK, rtapi_pci.cc pretty thoroughly reamed.
http://emergent.unpythonic.net/files/sandbox/rtapi_pci.cc if you want to review it.
[03:02:33] <jepler> 'night all
[03:02:49] <skunkworks_> night - thanks for all your work!
[03:06:39] <jepler> cradek: (I think the reaming also fixes the multi-device stuff but of course I can't test it)
[03:07:29] <jepler> compared to the previous version, 144 insertions, 506 deletions (so I deleted nearly 40% or so)
[03:08:02] -!- memfrob [memfrob!~memfrob@unaffiliated/memfrob] has joined #linuxcnc-devel
[03:08:20] <memfrob> hi seb_kuzminsky how did the patch go? get a chance to test it?
[03:12:33] -!- syyl_ has quit [Ping timeout: 240 seconds]
[03:24:43] <cradek> jepler: we could borrow up to all 3 5i20s from my machines
[03:24:51] <cradek> seb_kuzminsky:
http://timeguy.com/cradek-files/emc/installer-failsafe.png
[03:28:05] <cradek> fwiw, latest image will be on wlo in ~ 1hr
[03:29:00] <cradek> 0189184d4636939f7a31c3b3af8119df
[03:48:21] <skunkworks_> I have more than 1 5i25 I could test too
[03:50:58] <skunkworks_> I would have to find a motherboard with more than one pci slot
[03:50:59] <skunkworks_> ;)
[04:01:12] -!- patrickarlt has quit [Ping timeout: 255 seconds]
[04:02:29] -!- Thetawaves has quit [Quit: Leaving]
[04:13:23] -!- lyzidiamond has quit [Remote host closed the connection]
[04:19:03] -!- tronwizard has quit [Remote host closed the connection]
[04:45:53] -!- scooty_puff has quit [Remote host closed the connection]
[05:02:48] -!- ve7it has quit [Remote host closed the connection]
[05:02:55] -!- Fox_Muldr has quit [Ping timeout: 244 seconds]
[05:28:40] -!- FinboySlick has quit [Quit: Leaving.]
[05:40:41] -!- zee-Lathe has quit [Ping timeout: 252 seconds]
[05:56:38] -!- dybskiy has quit [Ping timeout: 252 seconds]
[06:19:48] -!- archivist_herron has quit [Ping timeout: 255 seconds]
[06:25:26] -!- tjtr33 has quit [Quit: Leaving]
[06:25:42] -!- dybskiy_ has quit [Remote host closed the connection]
[06:28:26] prtksxna is now known as zz_prtksxna
[06:31:10] -!- va7cdb has quit [Quit: va7cdb]
[06:42:30] -!- zee-Lathe has quit [Ping timeout: 248 seconds]
[06:45:33] -!- PetefromTn_ has quit [Quit: Copywight 2014 Elmer Fudd. All wights wesewved.]
[06:49:13] <memfrob> skunkworks_, think my board has about 4 of those slots :)
[06:51:18] -!- rob_h [rob_h!~robh@94.2.238.195] has joined #linuxcnc-devel
[06:52:38] -!- bedah has quit [Quit: Ex-Chat]
[07:14:58] -!- The_Ball has quit [Remote host closed the connection]
[07:36:38] zz_prtksxna is now known as prtksxna
[07:53:56] -!- dan2k3k4 has quit [Ping timeout: 244 seconds]
[07:55:59] -!- sylphiae has quit [Ping timeout: 252 seconds]
[07:59:18] prtksxna is now known as zz_prtksxna
[08:01:10] zz_prtksxna is now known as prtksxna
[08:08:08] -!- karavanjo_ has quit [Remote host closed the connection]
[08:21:20] prtksxna is now known as zz_prtksxna
[08:33:11] -!- WyrM has quit [Ping timeout: 272 seconds]
[08:34:03] -!- gonzo__ has quit [Ping timeout: 240 seconds]
[09:00:53] -!- balestrino has quit [Ping timeout: 252 seconds]
[09:05:10] -!- amiri has quit [Ping timeout: 264 seconds]
[09:16:42] -!- Thetawaves_ has quit [Quit: This computer has gone to sleep]
[09:23:32] -!- Vq has quit [Ping timeout: 245 seconds]
[09:25:55] -!- dybskiy has quit [Remote host closed the connection]
[09:30:59] zz_prtksxna is now known as prtksxna
[09:53:11] amnesic_away is now known as amnesic
[10:04:08] -!- sirdancealot has quit [Ping timeout: 244 seconds]
[10:14:13] -!- Khetzal has quit [Remote host closed the connection]
[10:15:41] -!- skunkworks_ has quit [Ping timeout: 252 seconds]
[10:18:03] prtksxna is now known as zz_prtksxna
[10:18:22] -!- Khetzal [Khetzal!~khetzal@sierra.khetzal.info] has joined #linuxcnc-devel
[10:21:49] amnesic is now known as amnesic_away
[10:33:24] -!- FreezingCold has quit [Ping timeout: 260 seconds]
[11:04:35] -!- lexano has quit [Ping timeout: 244 seconds]
[11:06:08] -!- somebub has quit [Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140608211810]]
[11:08:43] -!- balestrino has quit [Ping timeout: 244 seconds]
[11:15:55] -!- lyzidiamond has quit [Remote host closed the connection]
[11:29:23] <jepler> both the "two cards of one type" and "two cards of same type" cases would be interesting to actully test
[11:31:52] <jepler> including if we had two different hal components that both used the rtapi_pci_register_driver APIs
[11:33:27] <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
[11:34:31] <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
[11:57:01] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:15:35] -!- Valen has quit [Quit: Leaving.]
[12:17:47] -!- likevinyl has quit [Quit: likevinyl]
[12:21:54] -!- glontu has quit [Quit: Leaving]
[12:23:07] -!- kengu has quit [Ping timeout: 245 seconds]
[12:33:54] <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
[12:34:57] -!- md-2 has quit [Remote host closed the connection]
[12:37:08] <jepler> skunkworks: do you know what chipsets are on each one?
[12:37:42] <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..
[12:39:20] <jepler> looks like the onboard is Intel Corporation 82567V-2 Gigabit and the card is Intel Corporation 82574L Gigabit
[12:39:52] -!- md-2 has quit [Ping timeout: 260 seconds]
[12:40:34] -!- XXCoder has quit [Ping timeout: 264 seconds]
[12:46:00] -!- b_b has quit [Changing host]
[12:46:04] -!- dnaleromj [dnaleromj!~dnaleromj@98.124.126.110] has joined #linuxcnc-devel
[12:47:19] -!- micges-dev1 [micges-dev1!~x@evd25.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[12:49:03] -!- micges-dev has quit [Ping timeout: 255 seconds]
[12:49:51] <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)
[12:50:09] <skunkworks> let me look at the chipsets
[12:50:37] <skunkworks> I am seeing about .001ish following error at 1200ipm ;)
[12:50:58] <skunkworks> (spikes - not static error)
[12:54:22] <pcw_home> that represents about 50 usec latency
[12:55:08] -!- lmpyspaceprncs has quit []
[12:56:35] <pcw_home> (actual pulse count deviation will be much smaller due to the low gain of the PID loop)
[12:59:55] <skunkworks> this is the current system
http://pastebin.com/Azqs3VDq
[13:00:53] <jepler> to be honest, I'd have guessed the realtek would be the bad nic and the intel would be the good one
[13:01:20] <pcw_home> Yeah the 8111/8169 seems to be the most common NIC by far for low cost MBs
[13:02:09] <jepler> That's what my AMD desktop/server has, and it does work fine for day to day
[13:02:42] <jepler> on the other hand, in the past there have been troubles, and I think people have had trouble with rtai and realtek nics
[13:02:50] <pcw_home> It may be the PCI transfer time/blockage by other I/O that makes the intel slower or higher latency
[13:03:10] <jepler> PCI-E might be a tiny bit better then
[13:03:18] <pcw_home> Yeah i remember the RTK8139s had a huger list of bugs
[13:03:30] <pcw_home> well huge
[13:05:51] <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)
[13:06:46] <pcw_home> PCIE is more like a network of buffered switches instead of a shared bus
[13:06:48] <pcw_home> so theoretically there less likelyhood of blocking from bus mastering etc
[13:07:57] <pcw_home> (or at least the blockages are closer to the CPU where bandwidth is higher)
[13:10:02] -!- md-2 has quit [Ping timeout: 252 seconds]
[13:13:45] -!- FreezingCold has quit [Ping timeout: 272 seconds]
[13:19:44] <jepler> anything past ISA is black magic that I'm willing to accept as working..
[13:21:30] -!- lyzidiamond has quit [Ping timeout: 244 seconds]
[13:21:39] <jepler> I went ahead and started a wiki page on uspace.
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Uspace
[13:21:42] <jepler> afk
[13:27:38] -!- Lathe_newbie has quit [Ping timeout: 252 seconds]
[13:31:19] -!- dan2k3k4 has quit [Ping timeout: 244 seconds]
[13:33:03] -!- skorasaurus has quit [Remote host closed the connection]
[13:34:01] <memfrob> what does that page mean by unified?
[13:34:06] <memfrob> (rtapi name)
[13:37:21] -!- skorasaurus has quit [Remote host closed the connection]
[13:38:39] -!- skorasaurus2 has quit [Remote host closed the connection]
[13:41:01] <skunkworks> still running - even goes into screen saver
[13:41:08] -!- dan2k3k4 has quit [Ping timeout: 244 seconds]
[13:43:52] <skunkworks> I think he is just refering to ubc - unified build canidate..
[13:46:14] <pcw_home> I just turned off my ubc3-7i80 test (to try uspace-hm2-eth)
[13:46:15] <pcw_home> but it ran 70 days at 2 KHz with no issues
[13:48:08] <skunkworks> seems like jeff implimentation should be even better
[13:49:46] <pcw_home> It seems to have a bit lower latency (maybe 1 or20 %) for whatever reason
[13:49:55] <pcw_home> 10 or 20%
[13:51:01] <pcw_home> but i have only run it a few hours so far so that may be just measurement error
[13:52:02] <skunkworks> I think he said there is a little better realtime hardening with it..
[13:52:03] -!- i_tarzan has quit [Ping timeout: 240 seconds]
[13:55:52] <skunkworks> pcw_home, what are you running it on?
[13:55:59] <skunkworks> (what os)
[13:56:01] <pcw_home> 70 days at 2 KHz is 3.6288e10 packets!
[13:56:13] <skunkworks> wow
[13:56:57] <pcw_home> gigabyte J1800 MB Ubuntu 12.04 Preemt-RT 3.12.16
[13:57:26] <mozmck> can you do something like isocpus with preempt-rt and does it help latency?
[13:57:42] <pcw_home> I think i tried and it made it worse
[13:57:50] <skunkworks> I know idle=poll seems to help just a little
[13:58:06] <jepler> memfrob: whatever the right name is for the machinekit userspace rtapi implementation
[13:58:27] <mozmck> interesting.
[13:58:55] <jepler> mozmck: I haven't tried with isolcpus. It's possible it could make a small difference.
[13:58:56] <skunkworks> it surely helps the rtai.. 30us vs 10us
[13:59:08] <skunkworks> (idle = poll)
[14:00:05] <jepler> hm, looks like I'm using cpu_dma_latency not quite right
[14:00:21] <jepler> I'm not supposed to write the number as ascii ("0\n"), I'm supposed to write it as an integer
[14:00:24] <jepler> wonder if that makes a difference
[14:00:37] -!- skorasaurus2 has quit [Ping timeout: 272 seconds]
[14:00:46] <pcw_home> If you use isolcpus you would probably need to set the irq affinities as well
[14:00:54] <mozmck> how would you make the realtime stuff use the isolated core?
[14:01:19] <cradek> jepler: can uspace know whether it is running under an RT-PREEMPT kernel?
[14:01:39] <mozmck> what are irq affinities?
[14:01:55] <cradek> jepler: I ask because it might be nice to avoid the combination of hardware access and no realtime guarantees
[14:02:09] <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
[14:02:38] <cradek> cool
[14:03:02] <pcw_home> mozmck: which CPU handles which interrupt
[14:03:25] <mozmck> ah, ok thanks.
[14:03:36] <cradek> jepler: I like the wiki page, thanks
[14:03:43] <jepler> mozmck: the processor ID that a task runs on can be set with a call to "pthread_attr_setaffinity_np"
[14:03:45] -!- skors has quit [Ping timeout: 255 seconds]
[14:04:19] <mozmck> I see, so it would have to be done in code as well as setting isolcpus
[14:04:40] <jepler> my code right now checks the number of online CPUs and then sets all realtime threads to run only on processor #(nprocs-1)
[14:05:04] <mozmck> does that help latency?
[14:05:05] <jepler> I'm not sure how sysconf(_SC_NPROCESSORS_ONLN) interacts with isolcpus, I'd have to research it
[14:05:54] <jepler> they all run on the same core primarily so that the "rate monotonic scheduling" guarantee can be made
[14:06:40] <jepler> (which says that the slow thread never interrupts the fast thread; running on two CPUs at the same time is equivalent to interrupting)
[14:10:26] -!- patrickarlt has quit [Remote host closed the connection]
[14:13:25] <jepler> pcw_home: 3 packets per servo period?
[14:13:45] <jepler> request-read, read-response, write?
[14:14:29] <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
[14:14:37] <cradek> no sorry, I went to bed
[14:14:51] <skunkworks> oh the humanity...
[14:15:58] -!- patrickarlt has quit [Ping timeout: 264 seconds]
[14:16:24] <pcw_home> yes three packets
[14:20:33] <pcw_home> a two packet mode is possible:
[14:20:35] <pcw_home> write packet includes write data, wait-on-DPLL, read and send next read data
[14:20:36] <pcw_home> this has the advantage that the read data can be sent a wire time ahead so theres
[14:20:38] <pcw_home> no time wasted polling for read data
[14:24:52] <pcw_home> but this requires that all read data that may be needed the next cycle is
[14:24:54] <pcw_home> requested each time, basically hardwiring the process data list (no random reads)
[14:25:01] micges-dev1 is now known as micges-dev
[14:25:33] <mozmck> can you have a separate read command for that?
[14:26:13] <jepler> so far one packet has been big enough for everything to read or write?
[14:26:27] <mozmck> In one of my projects I have a command which writes and also is a read command, but another command for read only.
[14:26:29] -!- witnit has quit [Ping timeout: 252 seconds]
[14:26:48] <jepler> there are certainly conditional writes (index latch)
[14:26:52] <pcw_home> Yes 1500 bytes is plenty
[14:27:38] -!- jduhls has quit [Ping timeout: 244 seconds]
[14:28:27] <pcw_home> yeah but conditional writes could be done away with
[14:28:59] <jepler> a 1500 byte packet at 100 megabit/second is 150us? You don't get many full packets at 2kHz.
[14:29:05] -!- thomaslindstr_m has quit [Quit: Leaving...]
[14:29:57] <pcw_home> no but even 128 bytes is pretty big for normal systems
[14:30:58] -!- balestrino has quit [Ping timeout: 264 seconds]
[14:31:17] <jepler> that's true, if epp ever worked then 100Mbit ethernet must be far and away fast enough
[14:31:29] -!- skors has quit [Read error: Connection reset by peer]
[14:31:39] <pcw_home> a 6 axis servo system with say 384 I/O bits will fit in 128 bytes
[14:42:52] <cradek> jepler: that sure looks cleaner, but it's esoteric enough that I don't think I can be a useful reviewer
[14:47:03] <cradek> jepler: in rtapi_request_firmware, if uname fails, uninitialized fd gets used
[14:50:33] <cradek> in rtapi_pci_register_driver, dev is leaked if driver->probe() fails
[14:53:15] -!- quiqua has quit [Ping timeout: 255 seconds]
[14:56:44] -!- sylphiae has quit [Ping timeout: 252 seconds]
[14:57:05] <jepler> both those notes added to my TODO list
[14:58:06] <jepler> cradek: I don't have a deep understanding of the pci code either
[14:58:49] <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
[14:59:42] <cradek> that helps
[15:01:32] <jepler> so for instance, once you establish that you want to talk to this device
[15:01:34] <jepler> 09:47:03 <+cradek> jepler: in rtapi_request_firmware, if uname fails, uninitialized fd gets used
[15:01:44] <jepler> 04:00.0 Bridge: PLX Technology, Inc. PCI9030 32-bit 33MHz PCI <-> IOBus Bridge
[15:01:56] <jepler> and you decide you want mmio region 5, you have to mmap
[15:02:08] <jepler> sys/devices/pci0000:00/0000:00:1e.0/0000:04:00.0/resource5
[15:03:15] <jepler> .. and that's really all there is to it. after that, you just do memory read/write ops on that region of memory
[15:03:49] <jepler> oh I guess you have to enable and disable devices too. that must do .. something
[15:03:52] <jepler> power saving?
[15:18:04] <memfrob> jepler cradek how long have you guys been developing with linux? you guys know a lot.
[15:22:03] -!- lyzidiamond has quit [Ping timeout: 240 seconds]
[15:22:31] <skunkworks> cradek, jepler, usb ports don't work with rtai kernel - do work with the debian -rt kernel...
[15:23:21] <memfrob> skunkworks, the 3.4.55 kernel? i think someone else had the same problem.
[15:23:40] <skunkworks> whatever is on the latest livecd that cradek made..
[15:23:44] <memfrob> ohh.
[15:23:46] <skunkworks> I don't reember
[15:23:59] <skunkworks> I would have to look
[15:24:05] <memfrob> thats not mine then, nvm
[15:24:16] <skunkworks> I think whatever seb was working on
[15:24:32] <skunkworks> it is running the 7i80 with no issues.
[15:25:00] -!- jthornton has quit [Quit: Ex-Chat]
[15:25:58] <skunkworks> (the gigabyte J1800)
[15:26:18] <skunkworks> pcw_home, and the vidoe seems decent - glxgears is smooth - (wheezy_
[15:26:29] <jepler> memfrob: I've been using linux since '93, so I've had a few years
[15:26:52] <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?
[15:27:05] <skunkworks> sure
[15:28:02] <cradek> memfrob: I think this was the first Linux system I used:
http://timeguy.com/cradek-files/01188356148/yggdrasil-beta.jpg
[15:28:07] -!- JT-Shop has quit [Quit: Ex-Chat]
[15:28:17] <cradek> I still have the cd (or did a few years ago)
[15:28:39] <memfrob> wow!
[15:28:43] -!- Einar1 has quit [Quit: Leaving.]
[15:29:04] <archivist> yggrasil dates me too but later version
[15:30:22] -!- mozmck has quit [Ping timeout: 264 seconds]
[15:30:58] -!- jerryitt has quit [Quit: Connection closed for inactivity]
[15:31:41] <skunkworks> cradek,
http://pastebin.ca/2817571
[15:32:50] <cradek> skunkworks: could you include the full boot output please?
[15:33:01] <skunkworks> sure - sorry
[15:38:24] -!- JT-Shop [JT-Shop!~john@162.72.138.27] has joined #linuxcnc-devel
[15:41:19] <skunkworks> cradek,
http://pastebin.com/wxcT5RLi
[15:43:11] <skunkworks> (I just switched the hd from the asus motherboard to the gigabit motherboard
[15:44:18] -!- va7cdb has quit [Quit: va7cdb]
[15:44:39] -!- mozmck [mozmck!~moses@67.210.159.129] has joined #linuxcnc-devel
[15:46:41] <cradek> but this dmesg is from the hardware that has nonworking usb with seb's kernel?
[15:46:51] <skunkworks> correct
[15:47:06] <skunkworks> do you want a dmesg booting the rtai kernel?
[15:47:20] <cradek> huh, comparing those kernel configs, I don't see any meaningful differences
[15:47:28] <cradek> sure, please
[15:48:51] -!- gazprom has quit [Ping timeout: 264 seconds]
[15:50:07] <cradek> jepler: if rtapi_iounmap does not find the mapping, it goes ahead and munmaps/erases some things anyway
[15:54:27] -!- sumpfralle has quit [Ping timeout: 255 seconds]
[15:54:38] <skunkworks> cradek,
http://pastebin.com/cxRqKEe2
[15:55:08] <jepler> > [ 17.023978] usb 3-1: device not accepting address 2, error -110
[15:55:18] <jepler> does this happen in both kernels, or just in the broken kernel?
[15:55:22] -!- md-2 has quit [Remote host closed the connection]
[15:55:35] <cradek> good:
http://pastebin.com/wxcT5RLi bad:
http://pastebin.com/cxRqKEe2
[15:55:57] -!- md-2 has quit [Remote host closed the connection]
[15:56:11] <cradek> [just in the broken one]
[15:56:41] -!- thomaslindstr_m has quit [Quit: Leaving...]
[15:57:17] <jepler> so all the real usb ports are apparently behind this hub that won't enumerate, usb 3-1
[15:57:21] amiri_ is now known as amiri
[15:57:53] <jepler> since the plugged in devices are at 3-1.4 and 3-1.3.2
[16:02:14] <cradek> USB error -110: USB power exceeded
[16:06:11] <jepler> http://lists.xenproject.org/archives/html/xen-users/2014-03/msg00027.html
[16:06:15] <jepler> they think it has something to do with acpi
[16:06:25] <cradek> you could try setting ehci-hcd's ignore_oc=true
[16:06:34] <cradek> "ignore bogus hardware overcurrent indications"
[16:06:46] <skunkworks> is that a kernel line command?
[16:06:55] <cradek> no, a modprobe parameter
[16:07:16] <jepler> is there a way to set it for the installer?
[16:07:35] <cradek> not sure - test it first
[16:08:13] <cradek> skunkworks: create /etc/modprobe.d/whatever.conf, containing the line: options ehci_hcd ignore_oc=1
[16:08:43] -!- sumpfralle has quit [Read error: Connection reset by peer]
[16:08:50] <skunkworks> ok
[16:13:15] <cradek> jepler: and if you follow it, that the acpi problem has something to do with uefi
[16:13:53] <cradek> if this is a uefi problem, shoot me
[16:15:29] zz_prtksxna is now known as prtksxna
[16:19:22] -!- jthornton [jthornton!~john@162.72.138.27] has joined #linuxcnc-devel
[16:19:23] <jepler> cradek: sorry, I don't have a gun
[16:20:26] <cradek> ignore_oc also defaults to off, in 3.2.0-4-rt-686-pae
[16:21:03] -!- syyl_ has quit [Ping timeout: 240 seconds]
[16:21:10] -!- syyl_ws has quit [Ping timeout: 248 seconds]
[16:22:46] <cradek> jepler: did you see above about iounmap
[16:24:02] <jepler> cradek: yes
[16:25:33] -!- sumpfralle has quit [Ping timeout: 240 seconds]
[16:26:11] <skunkworks> assuming I typed it in right - it didn't help
[16:26:18] <skunkworks> still get the 110 errros
[16:26:20] <skunkworks> error
[16:26:26] <skunkworks> and no mouse or keyboard
[16:26:59] <cradek> skunkworks: you can check it with: cat /sys/module/ehci_hcd/parameters/ignore_oc
[16:27:22] -!- rob_h has quit [Ping timeout: 264 seconds]
[16:30:04] <skunkworks> it comes back N
[16:30:18] <cradek> then you haven't done something right, should be Y now
[16:30:57] <cradek> you rebooted after creating it?
[16:31:09] <skunkworks> hmm I double checked the line it is options ehci_hcd ignore_oc=1
[16:31:11] <skunkworks> yes
[16:31:47] <skunkworks> in a file named usboc.conf
[16:31:59] <cradek> hmm
[16:32:01] <cradek> lemme try here
[16:32:04] <skunkworks> in the etc/modprobe.d dirctory
[16:32:06] <skunkworks> directory
[16:33:54] <cradek> does your bios have UEFI/Legacy option?
[16:34:12] <skunkworks> I think so - but I think I tried it both ways. (I can try it again)
[16:34:26] <cradek> hm that modprobe option doesn't work for me either
[16:35:46] prtksxna is now known as zz_prtksxna
[16:37:13] -!- k6mle-CNC has quit [Ping timeout: 246 seconds]
[16:38:20] <cradek> after adding that file, you have to run dpkg-reconfigure linux-image-3.4-9-rtai-686-pae
[16:39:01] <cradek> and reboot yet again
[16:41:41] <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)
[16:42:09] <skunkworks> I have to hit the pause button twice to get it to take back off
[16:42:17] <cradek> eww
[16:42:57] <skunkworks> (I am used to ctrl-alt-t bringing up the terminal window.. - and I notice the linuxcnc stopped..)
[16:43:13] <skunkworks> linuxcnc noticed the t
[16:45:40] <jepler> hm, a new pause/step problem? I wonder if it bisects to before or after the new tp
[16:45:44] <jepler> (I mean whether)
[16:46:11] <cradek> skunkworks: is this 2.6 or master?
[16:46:15] <skunkworks> cradek, it is Y now - but no mouse/keyboard
[16:46:16] <skunkworks> master
[16:46:29] <cradek> oh good
[16:46:42] <cradek> let's just all imagine 2.6 works right and not test it
[16:46:48] <cradek> skunkworks: still error -110?
[16:48:01] <skunkworks> let me look
[16:48:45] -!- larryone has quit [Quit: This computer has gone to sleep]
[16:49:01] <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..
[16:49:45] <cradek> I don't know what T (step) while running should do
[16:49:51] <cradek> nothing crazy, I guess
[16:50:02] <cradek> probably should finish the current move and then pause
[16:51:21] <skunkworks> still error -110
[16:51:35] <cradek> does it say ehci_hcd ... USB 2.0 started, ... overcurrent ignored
[16:51:41] <cradek> (mine does)
[16:52:16] <jepler> I'm not sure whether the identification of error -110 with overcurrent is right
[16:52:29] <jepler> it's the return value of hub_set_address, which returns negative errno values
[16:52:45] <cradek> oh...
[16:52:48] <jepler> 110 is ETIMEDOUT
[16:52:49] <cradek> google, I trusted you
[16:52:59] <cradek> sigh
[16:53:12] <jepler> which sort of makes sense, as it happens seconds and seconds after it tries to initialize the hub
[16:53:15] <skunkworks> mine says that also..
[16:53:16] -!- bertrik has quit [Ping timeout: 260 seconds]
[16:53:37] <cradek> sorry about the goose chase
[16:54:12] <skunkworks> no problem.. I have seen people say unloading the ehci_hcd module fixes it.. but it didn't for me.
[16:56:09] <cradek> did the older 3.4.55-rtai kernel give working usb on this board?
[16:57:28] <jepler> cradek: let's go find lunch.
[16:57:35] <cradek> mmm lunch
[17:06:55] -!- lyzidiamond has quit [Remote host closed the connection]
[17:07:19] -!- md-2 has quit [Quit: Leaving...]
[17:16:21] -!- Loetmichel has quit [Ping timeout: 255 seconds]
[17:17:57] <memfrob> OC as in overclock?
[17:19:42] <seb_kuzminsky> oc as in over-current protection
[17:21:32] <memfrob> fail..
[17:21:59] <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
[17:22:05] <seb_kuzminsky> maybe i'll get to test it tonight
[17:24:46] -!- md-2 has quit [Remote host closed the connection]
[17:25:33] amnesic_away is now known as amnesic
[17:30:12] <memfrob> the 3.4.96?
[17:31:29] <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
[17:35:24] <skunkworks> neat
[17:35:48] <skunkworks> is 3.4.55 what was on the 10.04 livecd?
[17:36:39] <memfrob> no i believe it was 2.6 based
[17:40:49] <seb_kuzminsky> memfrob is right, the 10.04 live cd shipped with 2.6.32 iirc
[17:41:01] <seb_kuzminsky> 3.4.55 was the previous precise rtai kernel i made form shabby's repo
[17:41:22] <skunkworks> ah
[17:41:24] <seb_kuzminsky> then i made 3.4.87, which has problems on dgarr's computer and on one of mine
[17:41:40] <seb_kuzminsky> now i'm making 3.4.96, from a new rtai patch that memfrob made to see if that fixes it
[17:42:28] <skunkworks> sounds great
[17:42:51] <memfrob> im sure it will run fine
[17:42:55] <memfrob> :P
[17:43:12] <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
[17:51:17] <skunkworks> jepler, Ummm - so I just noticed that I am running the 7i80 with your ethernet branch - but booted the rtai kernel...
[17:52:15] <jepler> skunkworks: interesting. how's the latency?
[17:53:28] <skunkworks> let me check.. it has been running the splash screen with no FE
[17:55:41] <skunkworks> jepler after a few bit - base thread is aproching 1ms - servo thread around 50us
[17:56:09] -!- sylphiae has quit [Quit: Leaving]
[17:56:11] <skunkworks> up to 75us
[17:56:28] <skunkworks> how is that even working?
[17:57:27] <skunkworks> seems to be leveling out at 75us/900us
[17:59:38] <pcw_home> may have more sane results if you delete the base thread
[18:00:22] -!- md-2 has quit [Ping timeout: 264 seconds]
[18:00:33] <skunkworks> I am just suprised it is working at all :)
[18:01:10] <skunkworks> a) that it initialized the card correctly and b) loaded linuxcnc and c) ran without following errors..
[18:01:12] <seb_kuzminsky> skunkworks: interesting
[18:01:29] <skunkworks> feature by design?
[18:01:30] <seb_kuzminsky> i've only been listening with half an ear to y'all's debugging
[18:01:42] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[18:02:56] <micges-dev> weird that there are no overruns
[18:03:52] <skunkworks> overruns are disabled at the moment...
[18:04:07] <skunkworks> so I have been using following error as a sort of test...
[18:04:27] <micges-dev> ah
[18:05:09] <skunkworks> heh - I did a latency-test -h and it errored in terminal and ran with just the servo thread...
[18:08:33] -!- syyl has quit [Ping timeout: 255 seconds]
[18:13:27] -!- kfoltman has quit [Quit: Ex-Chat]
[18:13:57] -!- larryone has quit [Ping timeout: 255 seconds]
[18:19:22] <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
[18:19:46] <skunkworks> *latency stays under 35us
[18:23:45] <skunkworks> still interesting that it worked - I would think I would get scolded.
[18:26:30] -!- Guest22237 has quit [Ping timeout: 248 seconds]
[18:31:09] -!- va7cdb has quit [Quit: va7cdb]
[18:37:18] -!- rob_h [rob_h!~robh@94.2.238.195] has joined #linuxcnc-devel
[18:41:26] Cylly is now known as Loetmichel
[18:52:50] -!- Guest22237 has quit [Quit: Leaving]
[18:54:29] -!- skors has quit [Remote host closed the connection]
[19:01:08] -!- md-2 has quit [Ping timeout: 260 seconds]
[19:05:05] -!- sumpfralle has quit [Ping timeout: 244 seconds]
[19:11:00] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[19:14:42] -!- sheppard has quit [Ping timeout: 255 seconds]
[19:14:43] -!- `Nerobro has quit [Remote host closed the connection]
[19:15:27] -!- skors has quit [Remote host closed the connection]
[19:17:37] <jepler> skunkworks: there's not any scolding built in yet
[19:17:47] <skunkworks> heh
[19:18:00] <jepler> though cradek thinks I should add it (specifically, if running on rt-preempt, have hardware drivers refuse to load)
[19:18:05] <jepler> (er, if not running on rt-preempt)
[19:18:23] <jepler> but also I know I need to add some form of overrun detection
[19:18:31] <jepler> I think I can use what rtai does as a guideline
[19:19:02] -!- skors has quit [Remote host closed the connection]
[19:19:13] amnesic is now known as amnesic_away
[19:22:27] -!- lyzidiamond has quit [Remote host closed the connection]
[19:23:49] -!- syyl_ws has quit [Quit: Verlassend]
[19:24:53] -!- abetusk has quit [Ping timeout: 272 seconds]
[19:28:03] -!- Lathe_newbie has quit [Ping timeout: 240 seconds]
[19:28:35] -!- witnit has quit [Remote host closed the connection]
[19:29:06] -!- gonzo___ has quit [Quit: Leaving]
[19:29:42] -!- skunkworks has quit [Read error: Connection reset by peer]
[19:30:35] -!- skorasaurus has quit [Remote host closed the connection]
[19:30:35] -!- sheppard has quit [Ping timeout: 272 seconds]
[19:34:29] <cradek> Gene sure thinks the 2.6 kernel hurts his swap. he has said it over and over. I wonder what's really wrong.
[19:36:34] bertrik_ is now known as bertrik
[19:38:19] abetusk is now known as Guest26006
[19:44:46] -!- asheppard has quit [Ping timeout: 264 seconds]
[19:47:59] -!- skorasaurus2 has quit [Remote host closed the connection]
[19:54:41] -!- skorasaurus2 has quit [Ping timeout: 244 seconds]
[19:54:58] -!- PetefromTn_ has quit [Quit: Easy as 3.14159265358979323846...]
[19:56:06] -!- skors has quit [Ping timeout: 248 seconds]
[19:57:02] -!- MacGalempsy has quit [Remote host closed the connection]
[20:01:48] -!- md-2 has quit [Ping timeout: 260 seconds]
[20:02:56] <seb_kuzminsky> new rtai kernel & modules: deb
http://highlab.com/~seb/linuxcnc/rtai-debs precise main
[20:02:59] <seb_kuzminsky> (or wheezy main)
[20:03:20] <seb_kuzminsky> this is memfrob's 3.4.96 kernel patch and the good old modules from the 3.4.55 days
[20:03:31] <cradek> yay
[20:03:38] <seb_kuzminsky> i'm especially curious to see if this fixes dgarr's problem, and mine (when i get home tonight)
[20:03:50] <cradek> and skunkworks's
[20:04:01] <seb_kuzminsky> the usb thing? i haven't thought about that at all
[20:04:27] <seb_kuzminsky> thanks to you guys for working on debugging it while my attention's elsewhere, i appreciate the help
[20:04:59] <seb_kuzminsky> i just got notified by shabby that he re-wrote his rtai master branch again
[20:05:04] <seb_kuzminsky> so i should try that at some point too
[20:07:44] <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
[20:08:11] <seb_kuzminsky> i think this will be an easier and/or less error-prone way to maintain the rtai kernel patch
[20:11:11] <memfrob> yay 3.4.96 kernel is up woo!
[20:11:27] <memfrob> thanks seb_kuzminsky!
[20:11:49] <memfrob> seb_kuzminsky, i think the only way to fix the USB issue is to change the kernel config
[20:12:03] <memfrob> (which im perfectly fine doing btw but then you'll need to make new debs)
[20:12:28] <seb_kuzminsky> i dont use the kernel config from the rtai repo any more
[20:12:33] -!- likevinyl has quit [Ping timeout: 240 seconds]
[20:12:38] <memfrob> the config i gave you
[20:12:42] <seb_kuzminsky> i'm building the linux-image debs using the debian.org kernel configs
[20:12:47] <memfrob> oh thats why...
[20:13:05] <cradek> memfrob: what setting do you think will fix skunkworks's problem?
[20:13:08] <seb_kuzminsky> with custom configs, but maybe i messed them up
[20:13:29] <memfrob> cradek, well a lot of the debian default configs will conflict with RTAI
[20:13:30] <seb_kuzminsky> cradek: asking the questions that matter, since 1974
[20:14:22] <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
[20:14:51] <memfrob> default options in processor type in features and acpi should be changed for starters
[20:16:27] <memfrob> as for USB, most distros enable really weird stuff by default which i turn off, which ones i dont remember off hand.
[20:17:13] <memfrob> either way seb_kuzminsky will need to make new debs..
[20:17:54] <memfrob> unless of course the version bump magically fixes skunkwork's problem
[20:18:04] <seb_kuzminsky> making debs is time-consuming for my computer but quick for me (except when i find new bugs in my build scripts)
[20:18:26] <memfrob> should i make a config?
[20:18:54] <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
[20:19:54] <memfrob> in that case ill need a copy of the config used in debian
[20:20:24] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/rtai-kernel-configs
[20:27:40] -!- tronwizard has quit [Ping timeout: 255 seconds]
[20:28:01] <cradek> seb_kuzminsky: it boots -- building 2.6 for it now
[20:28:14] <seb_kuzminsky> does it run latency-test?
[20:28:26] <cradek> I can try the rtai one
[20:28:40] <seb_kuzminsky> thx
[20:29:19] <seb_kuzminsky> but this is on a machine that had no problems with the 3.4.87 kernel too, right?
[20:29:28] <cradek> yeah
[20:32:08] <cradek> nope, it doesn't run
[20:32:18] <cradek> rtai_hal: disagrees about version of symbol module_layout
[20:32:25] <cradek> latency_rt: [same]
[20:32:37] tronwzrd is now known as tronwizard
[20:33:11] <cradek> linux-image-* 3.4.96-1linuxcnc; rtai-modules-* 3.9.260.g6394e67
[20:34:52] -!- md-2 has quit [Quit: Leaving...]
[20:38:17] <cradek> I bet the version number is unchanged, so it didn't upgrade
[20:40:04] <cradek> I think I forced a reinstall from highlab, but it still fails to run rtai's testsuite test
[20:42:26] <cradek> ohhh you built what's actually a downgrade: rtai-modules-3.4-9-rtai-686-pae_3.9.246.g75d17f1_i386.deb
[20:42:38] <cradek> 246 < 260
[20:42:48] <seb_kuzminsky> yeah i rebased
[20:42:51] <seb_kuzminsky> and didnt tell anyone
[20:43:32] <seb_kuzminsky> i've been bouncing around different versions on different branches in the rtai repo like crazy
[20:43:36] <seb_kuzminsky> i'm all dizzy now
[20:43:48] <cradek> after the kernel upgrade and rtai-modules downgrade, it does run
[20:43:53] <seb_kuzminsky> heh
[20:44:11] <seb_kuzminsky> now you just need to sidegrade linuxcnc and retrograde gcc and you should be good
[20:44:32] <cradek> and denigrade seb_kuzminsky
[20:44:52] <seb_kuzminsky> heh
[20:50:23] -!- Nick001-shop has quit [Ping timeout: 252 seconds]
[20:54:21] <cradek> oh aram
[20:54:58] -!- Deejay has quit [Quit: bye]
[21:01:34] -!- skors has quit [Ping timeout: 264 seconds]
[21:02:46] -!- skorasaurus has quit [Ping timeout: 264 seconds]
[21:12:38] -!- jduhls has quit [Quit: Leaving]
[21:13:35] -!- tinkerer has quit [Quit: Leaving.]
[21:24:43] -!- skunkworks_ [skunkworks_!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:24:45] -!- GlennS has quit [Ping timeout: 255 seconds]
[21:25:36] <skunkworks_> logger[psha]_:
[21:27:12] <micges-dev> PCW: did you test mf package yet?
[21:28:01] amnesic_away is now known as amnesic
[21:28:03] <PCW> not yet let me try on the 12.04 Preemt RT system now
[21:29:18] <jepler> cradek: do you mean "denigrate"?
[21:35:29] -!- balestrino has quit [Ping timeout: 252 seconds]
[21:35:46] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[21:36:03] <cradek> yes but the spelling was on purpose...
[21:37:54] <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
[21:39:46] <PCW> micges-dev: seems to work (tested with 7I76E) what should I test?
[21:39:48] <PCW> (note RPO does not work with the Ethernet cards it reports EPP timeouts)
[21:40:33] <micges-dev> PCW: only if installed binary discover any board
[21:40:57] <micges-dev> PCW: checking that epp bug now
[21:41:54] <PCW> it also says it requires root access for PCI when accessing Ethernet cards
[21:43:17] <micges-dev> I didn't fixed that yet
[21:47:02] <micges-dev> PCW: you must always use --addr for accessing eth boards
[21:47:29] <micges-dev> x@x-desktop:~/PROJECTS/mesaflash3$ sudo ./mesaflash --device 7i76e --addr 192.168.1.121 --rpo 0x100
[21:47:29] <micges-dev> 55AACAFE
[21:48:43] -!- K6MLE-CNC has quit [Ping timeout: 246 seconds]
[21:48:49] <micges-dev> even without --addr I don't have any epp errors
[21:49:52] -!- jbr has quit [Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]]
[21:50:51] <skunkworks_> I was hoping my netgear old usb wireless adaptor would just work (tm) but it doesn't
[21:51:01] <PCW> peter@lcnc:~$ sudo mesaflash --device 7i76e --addr 10.10.10.10 --rpo 0x100
[21:51:02] <PCW> failed to clear EPP Timeout!
[21:51:04] <PCW> EPP timeout on data cycle of read(addr=0x0000, size=4)
[21:51:05] <PCW> failed to clear EPP Timeout!
[21:51:07] <PCW> EPP timeout on data cycle of read(addr=0x0100, size=4)
[21:51:08] <PCW> failed to clear EPP Timeout!
[21:51:10] <PCW> 55AACAFE
[21:52:41] <micges-dev> ok, does you pc have epp on board?
[21:53:23] <PCW> yes it has a parallel port that can do EPP
[21:54:53] <micges-dev> same here
[21:56:01] <micges-dev> ok, found error, in some strange way 10.10.10.10 isn't recognised as a ip address
[21:59:56] -!- bertrik has quit [Remote host closed the connection]
[22:02:03] <PCW> I would have thought the interface type would be determined by the device
[22:04:56] <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)
[22:05:11] -!- skorasaurus2 has quit [Ping timeout: 252 seconds]
[22:05:24] <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 :-(
[22:05:27] -!- kfoltman has quit [Read error: No route to host]
[22:06:01] <micges-dev> eww
[22:14:56] <memfrob> seb_kuzminsky, i found multiple things that could be cause of skunkworks's issue in regards to USB
[22:18:00] -!- patrickarlt has quit [Remote host closed the connection]
[22:18:20] <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
[22:20:11] -!- thomaslindstr_m has quit [Client Quit]
[22:21:53] <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.
[22:23:18] <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
[22:23:26] <memfrob> error 55 device unplugged etc.
[22:24:26] <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.
[22:24:44] <jepler> so none of those can be selecte as "m", if I correctly remember the disinction between bool and tristate
[22:26:01] <memfrob> im going to verify that really quick
[22:28:14] <memfrob> hid generic isnt being built at all..
[22:28:23] <memfrob> another problem^
[22:29:19] -!- gkamysz has quit [Ping timeout: 246 seconds]
[22:29:26] <memfrob> CONFIG_USB_DEFAULT_PERSIST isnt enabled..
[22:29:29] -!- patrickarlt has quit [Remote host closed the connection]
[22:30:48] <memfrob> i actually dont even have CONFIG_HID_SUPPORT in my kernel..
[22:31:10] <memfrob> its not even an option, nor USB_SUSPEND
[22:32:14] <memfrob> invalid config options in config file, not properly updated between kernel versions
[22:33:11] <jepler> (Starting with the 3.10 kernel release, dynamic PM support for USB is
[22:33:12] <jepler> present whenever the kernel was built with CONFIG_PM_RUNTIME enabled.
[22:33:12] <jepler> The CONFIG_USB_SUSPEND option has been eliminated.)
[22:33:32] <jepler> CONFIG_USB_SUSPEND is in Kconfig of seb's 3.4.87 tree
[22:33:44] <memfrob> PM_RUNTIME should be disabled for RTAI
[22:35:02] <memfrob> as should all suboptions in ACPI
[22:36:56] -!- Einar1 has quit [Quit: Leaving.]
[22:37:00] <memfrob> the only feature for RTAI that should be enabled is CONFIG_X86_PM_TIMER
[22:37:13] <memfrob> (under ACPI) ^
[22:39:36] <memfrob> if i had his dmesg output i might be able to help more but a lot of those options should be changed
[22:41:12] <memfrob> CONFIG_DEFAULT_CFQ=y CONFIG_HZ_250=y CONFIG_PREEMPT_VOLUNTARY=y CONFIG_HPET_MMAP=y
[22:42:11] <memfrob> CONFIG_OPTIMIZE_INLINING=y ive seen break things too
[22:45:15] <memfrob> CONFIG_SLAB=y is a no no, CONFIG_DEFAULT_MMAP_MIN_ADDR=65536 should be 4096 err..
[22:47:56] <memfrob> the rtai_32_defconfig is in much better shape from what i see than the other one in that link seb_kuzminsky posted
[23:01:21] -!- larryone has quit [Client Quit]
[23:11:52] -!- ibaca has quit [Ping timeout: 245 seconds]
[23:13:57] -!- archivist has quit [Ping timeout: 245 seconds]
[23:13:57] -!- ssi has quit [Ping timeout: 245 seconds]
[23:15:29] -!- archivist [archivist!~archivist@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[23:17:32] -!- patrickarlt has quit [Remote host closed the connection]
[23:17:38] zz_prtksxna is now known as prtksxna
[23:17:47] -!- thomaslindstr_m has quit [Quit: Leaving...]
[23:18:01] <cradek> jepler: those look great
[23:18:18] <cradek> jepler: I will keep trying to go through the rest...
[23:20:33] <cradek> memfrob: from earlier: good:
http://pastebin.com/wxcT5RLi bad:
http://pastebin.com/cxRqKEe2
[23:21:14] <cradek> "good" is the debian -rt kernel
[23:30:37] -!- sylphiae has quit [Ping timeout: 272 seconds]
[23:38:28] -!- va7cdb has quit [Quit: va7cdb]
[23:39:44] <memfrob> yes 3.4.87 is the bad one
[23:39:51] <memfrob> 3.4.96 should be the good one
[23:39:55] <memfrob> the new good one i mean
[23:42:02] -!- The_Ball has quit [Remote host closed the connection]
[23:43:15] -!- witnit has quit [Remote host closed the connection]
[23:45:03] -!- arturia has quit [Ping timeout: 240 seconds]
[23:46:10] <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.
[23:47:34] <memfrob> seb just recently made 3.4.96 debs
[23:57:40] <memfrob> its the same exact IPIPE code from the infamous 3.4.55 kernel
[23:58:48] <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
