Back
[09:06:49] <jepler> skunkworks: printing twice is slightly interesting. I assume that's a base-thread-only setup.
[09:06:57] <jepler> (so it's not that one should have been task 0, and one should have been task 1)
[09:07:20] <jepler> actually, I bet one is from realtime and the other is from task
[09:07:40] <jepler> not sure though
[09:19:23] <jepler> (task receives a copy of realtime errors and relays them to userspace; that's how axis gets its message pop-in
[09:19:26] <jepler> )
[10:53:13] <jepler> BUGS
[10:53:17] <jepler> It is not yet possible to change operating system by writing to
[10:53:20] <jepler> /proc/sys/kernel/ostype.
[11:00:06] <seb_kuzminsky> geez, someone should fix that
[11:00:17] <seb_kuzminsky> jepler: did you get my code-review comments?
[11:05:00] <jepler> seb_kuzminsky: found them
[11:06:35] <jepler> seb_kuzminsky: "normal" build sys was the kernel 2.4 pre-"kbuild" module build system.
[11:06:40] <jepler> its traces should be considered deletable
[11:13:21] <jepler> seb_kuzminsky: (thank you)
[11:27:29] <seb_kuzminsky> it's not the job of your rt-preempt branch to fix the BUILD_SYS=normal thing, i was just curious
[11:27:46] <seb_kuzminsky> i've made a note to remove it. at some point.
[12:08:22] <jepler> Instead of working on seb's review items, I worked on userspace parallel port stuff this morning.
[12:08:57] <jepler> I made the work harder than strictly necessary by also moving the parport stuff from the hal layer to the rtapi layer
[12:09:41] <jepler> it now loads hal_parport (the "real" one, not the copy-and-modify version that ended up in "simdrivers")
[12:50:40] <jepler> darn, 7i43 doesn't work on the first time, and now it's time to leave..
[14:33:01] <pcw_home> jepler: may just be PP issues if you are not using a built-in motherboard port
[14:50:32] <jepler> pcw_home: yes, it's an othherwise-untested pci-e parport
[14:50:42] <jepler> 03:00.0 Parallel controller: Oxford Semiconductor Ltd Device c110
[14:51:38] <jepler> I'll double check jumper setting and if I have to, install 32 bit linux and test with rtai
[14:51:43] <pcw_home> I have had Oxsemi PCI cards work so its likely OK
[14:52:03] <jepler> but for now I'll drink this wine and listen to live bluegrass
[14:52:29] <pcw_home> sounds like a plan
[14:58:43] <cradek> where does one find live bluegrass?
[15:56:58] <jepler> cradek: out at one of the local wineries. they're done now, unfortunately.
[15:57:09] <jepler> deer creek, out northeast of lincoln
[16:12:00] <jepler> cradek: I just "dd" the hybrid.iso to /dev/sdX and boot?
[16:19:32] <seb_kuzminsky> jepler: yep that should work
[16:20:12] <seb_kuzminsky> cradek: the wheezy install i got after an older version of your live image includes a couple of virtualbox gues support packages, and i think they should be removed
[16:21:05] <seb_kuzminsky> virtualbox-guest-dkms, virtualbox-guest-utils, and virtualbox-guest-x11
[16:21:41] <seb_kuzminsky> -dkms slows down "dpkg -i linux-image" on my anemic cnc machine, because it recompiles a bunch of kernel modules for the new incoming kernels
[16:31:26] <cradek> lemme see if I can figure out what pulled those in
[16:34:50] <cradek> oh good, they're explicit so it's easy to nuke 'em
[16:44:17] <jepler> whee, it's alive. First problem, this board needs epp_wide=0 :( and after that there was a silly crash-at-startup bug
[16:45:59] <CaptHindsight> just FYI, <$10 EPP PCIe adapter
http://www.ebay.com/itm/Parallel-Port-DB25-LPT-Printer-PCI-E-PCI-Express-Card-Converter-Adapter-/170988778068
[16:46:01] <jepler> seb, pcw: I might as well share with you my nightmare: for those mesa boards with DB connectors, somebody wrote an EPP FPGA firmware, so now I had to figure out tunneling though an arbitrary topology of hm2 boards
[16:46:32] <cradek> someone actually did it? I thought that was just a fever dream of yours.
[16:47:05] <cradek> oh, you mean literal nightmare
[16:47:16] <cradek> duh
[16:47:30] <jepler> this one's "startech.com Part # PEX1P". chip is silkscreened OXPCIe952-FBAG
[16:47:47] <jepler> cradek: yeah, not real
[16:48:24] <jepler> with a 1ms servo thread, "top" shows 20% of time spent in rtapi_app
[16:48:36] <jepler> .. just running the read/write/pet functions
[16:48:38] <cradek> on a fast or slow machine?
[16:49:00] <jepler> core2 duo 3.16GHz, so I think you'd call it fast
[16:49:24] <cradek> yeah
[16:49:29] <cradek> warning: script 'realtime' missing LSB tags and overrides
[16:49:41] <cradek> I wonder if this matters for any real reason
[16:49:44] <jepler> that means "geez, you shouldn't even put this in /etc/rc.d"
[16:52:26] <jepler> er /etc/init.d
[16:55:10] <pcw_home> jepler: the nightmare is here (there are people using 7I90s with hm2-serial driven by hm2-pci)
[16:55:32] <jepler> pcw_home: ah, hm
[16:55:41] <jepler> pcw_home: not linuxcnc?
[16:55:55] <pcw_home> no
[16:56:22] <pcw_home> 384 channels of scaler counters for a CT scanner
[16:56:36] <jepler> wow
[16:56:56] <pcw_home> 64 channels per 7I90
[17:02:08] <micges-dev> pcw_home: I fixed mf root access problem, testing with all my boards
[17:02:22] <pcw_home> rebooted uspace-hm2-eth a couple times and never saw the startup error again
[17:02:34] <jepler> pcw_home: huh, ok. I won't worry about that one, then
[17:04:11] <pcw_home> micges-dev: great It does bring up a interesting issue about Ethernet being accessible to all
[17:05:33] <micges-dev> issue?
[17:06:23] <pcw_home> how easy that makes it to break linuxcnc
[17:06:24] <pcw_home> I just did this yesterday by running mesaflash while linuxcnc was running
[17:06:26] <pcw_home> (I new It would fail at 2 KHz)
[17:07:09] <micges-dev> ah
[17:07:54] <pcw_home> Ive noticed at 1 KHz or so you can get away with running say RPO or WPO to read a parameter
[17:07:56] <pcw_home> while linuxcnc is running, but at 2 KHZ there not enough margin for random packets
[17:08:25] <micges-dev> right
[17:09:00] <pcw_home> I wonder if its as simple as setting permissions on the MAC device
[17:09:01] <pcw_home> or whether that has all sorts of side effects
[17:10:41] <micges-dev> yeah you can halt expensive cutting by trying to connect to internet accidentally
[17:11:07] <pcw_home> it would be better if you needed to
[17:11:09] <pcw_home> sudo ping 7i80 :-)
[17:11:52] <micges-dev> :)
[17:12:17] <pcw_home> better
[17:12:19] <pcw_home> sudo -u linuxcnc 7i80
[17:15:11] <micges-dev> probably tricky iptables script should help to protect hm2_eth <-> board connection
[17:17:39] <micges-dev> pcw_home: new syntax will be: ./mesaflash --device 7i90 --epp --rpo 0x100
[17:17:47] <micges-dev> you can use also --usb and --spi
[17:18:10] <micges-dev> (for 7i64 and 7i43)
[17:25:42] <pcw_home> still --addr for epp address?
[17:26:06] <pcw_home> (I guess 0x378 could be a default)
[17:26:12] <micges-dev> err yes
[17:26:27] <micges-dev> I try to defaullt it
[17:50:49] <seb_kuzminsky> i just ran ./configure on a machine with both 3.4-9-rtai-686-pae and 3.2-4-rt-686-pae on it, while i was running the -rt one (not -rtai), and configure got it wrong and built me an rtai linuxcnc
[17:51:13] <seb_kuzminsky> also, debian/configure got confused about the -rt kernel
[17:51:43] <seb_kuzminsky> i rewrote debian/configure for ubc, i'm going to look into pulling the ubc version into uspace
[17:53:56] <jepler> seb_kuzminsky: that'd be great. can it be its own topic, after merging uspace?
[17:54:27] <jepler> hm, I wonder how I broke tests/hm2-idrom
[17:54:38] <jepler> oh well, have to wait for the slow mdi tests before I can diagnose it more closely
[17:58:03] <seb_kuzminsky> sure, i'll put it on a side branch
[17:58:19] <seb_kuzminsky> i should be testing jepler/rtos-uspace-apis for hm2-pci, right?
[17:58:32] <seb_kuzminsky> kthxbbl
[17:58:40] <jepler> seb_kuzminsky: yes
[18:05:36] <jepler> oh, by making hal.is_rt be true, it went back to looking for failure messages in dmesg
[18:17:42] <jepler> seb_kuzminsky: for your consideration:
http://emergent.unpythonic.net/files/sandbox/0001-hm2_7i43-Automatically-fall-back-to-byte-transfers.patch
[18:18:27] <jepler> this autoselects !epp_wide mode on my flawed pci-e card
[19:18:51] <micges-dev> pcw_home: '--serial' option for selecting serialhm2 transport layer would be obvious?
[19:20:29] <pcw_home> yeah or ser-hm2
[19:22:18] <pcw_home> Just finishing the last 7I90 firmware option (sserial remote)
[19:22:19] <pcw_home> not sure if its worth supporting firmware upgrade on it though
[19:23:29] <micges-dev> seems not urgent job
[19:24:40] <micges-dev> but eventually you should add it for convenience
[19:24:55] <seb_kuzminsky> looks good jepler
[19:29:35] <seb_kuzminsky> at first it looks like a layer violation, and i guess it is, but if it's stpuid and it works then it's not stupid
[19:32:44] <jepler> seb_kuzminsky: yeah it is a bit
[19:46:20] <seb_kuzminsky> what happened to tests/hm2-idrom in rtos-uspace-apis?
[19:47:31] <seb_kuzminsky> looks like a "where did my logging output go?" issue
[19:59:37] <jepler> seb_kuzminsky: yes. it was working, but then I re-broke it when i changed what python's hal.is_rt returns
[19:59:58] <jepler> .. fix is in my tree, introduce new is_kernelspace attribute and use it to decide whether to try to fetch from stderr or dmesg
[20:00:12] <jepler> not yet pushed
[20:06:49] <seb_kuzminsky> ah, nice
[20:09:10] <jepler> yeah, too bad I hadn't bothered running the tests before I pushed the last round of rebases
[20:10:40] <jepler> seb_kuzminsky: forgive me if i asked this before, but do you think I should push uspace + apis as two steps, or one?
[20:10:58] <jepler> .. of course I won't be pushing eth, due to the known problems it causes for other hm2 code
[20:12:50] <jepler> .. and in what time frame do you think that (first) push should happen? I feel pretty good about the state of the code, but I can't say I've run it day and night on real hardware.
[20:12:57] <jepler> (cradek did run max with it)
[20:21:54] <andypugh> I wonder if Mach3 would work better for Aram than LinuxCNC?
[20:23:09] <jepler> yay, hal_parport works .. including -reset pins
[20:24:23] <jepler> .. hmm, what units are the reset-time in? It's not behaving like they're ns, unfortunately.
[20:24:48] <andypugh> That’s cool, though hal_parport already works… hm2_eth would be funner.
[20:25:06] <andypugh> reset should be in nS.
[20:25:30] <andypugh> The reset code watches the clock, and may be using rtapi_get_time
[20:25:53] <jepler> it's using rtapi_get_clocks + a value called "ns2tsc_factor"
[20:26:49] <andypugh> I think I have instructions on how to suck eggs here somewhere too.
[20:27:20] <jepler> .. but ns2tsc_factor just gets hardcoded
[20:27:27] <jepler> ugh, and then it locked up
[20:29:17] <jepler> well the code around -reset is a bit dubous as far as tsc wraparounds are concerned
[20:35:19] <andypugh> I will pedantically point out that you should never add a “factor”.
[20:35:49] <jepler> yes, sloppy wording^Wpunctuating on my part
[20:36:03] <cradek> southern comfort tastes like a slightly less sweet version of nyquil
[20:36:06] <andypugh> Time to sleep.
[20:36:10] <cradek> hi andy!
[20:36:15] <cradek> and goodnight
[20:36:25] <jepler> see you andy
[20:42:58] <seb_kuzminsky> jepler: i'd say push rtos-uspace-apis, dont bother doing rtos-uspace by itself
[20:43:22] <seb_kuzminsky> and then we'll wait for micges to fix hm2 in the -eth branch
[20:43:59] <seb_kuzminsky> cradek: liquor + sweet = fail
[20:44:18] <cradek> seb_kuzminsky: but I do love a good rum
[20:44:35] <jepler> seb_kuzminsky: OK. It's getting tedious to rebase 3 branches every time, so I'll concentrate on -apis
[20:44:42] <seb_kuzminsky> it should taste like degreaser, to remind you that you're dissolving your insides
[20:44:47] <jepler> .. but I'll try to keep the drivers work strictly after the rtos work
[20:44:56] <seb_kuzminsky> yeah, cool
[20:45:13] <seb_kuzminsky> jepler: that makes the pedant in me all ocd and happy
[20:46:03] <cradek> jepler: I'm happy about your work too
[20:46:11] <jepler> hm now I want to go back through rtapi and use 'struct timespec' everywhere
[20:47:14] <jepler> I know there's a wraparound bug in this parport reset code, and it's short-term enough that it's triggered twice since I announced -reset pins work
[20:47:34] <cradek> ouch
[20:47:38] <jepler> at least I'm assuming it's wraparound. Haven't been able to successfully attach a debugger after it's wedged
[20:48:25] <jepler> deadline = old_value_of_rtapi_get_clocks + reset_time_tsc; while(rtapi_get_clocks() < deadline) {}
[20:48:33] <seb_kuzminsky> you should write a component that monitors a hal pin for transitions and sends sigstop to a processes
[20:49:00] <jepler> all values are of type (signed) long longs, I think
[20:49:25] <jepler> so rtapi_get_clocks() shouldn't be wrapping around very often
[20:55:03] <seb_kuzminsky> reading jepler/rtos-uspace is like reading a spy novel or a thriller or something
[20:55:22] <seb_kuzminsky> all this stage-setting and build up, then BOOM "uspace: Implement POSIX realtime"
[20:55:51] <jepler> heh
[20:57:33] <jepler> In at least one incarnation of that history, I broke the RT hardening into its own commit
[20:58:18] <seb_kuzminsky> wth does mallopt(M_MMAP_MAX, 0) mean? "A value of 0 disables the use of mmap()."
[20:59:02] <seb_kuzminsky> i dont think you need + /* Touch each page in this piece of memory to get it mapped into RAM */
[20:59:16] <seb_kuzminsky> since you already did mlockall(MCL_FUTURE)
[20:59:24] <jepler> the last thing you said I agree with
[20:59:35] <seb_kuzminsky> err, i should have written that in my code review file instead of in irc
[20:59:50] <seb_kuzminsky> bbl, time to be a family man for a bit
[20:59:53] <jepler> so I think the idea is this: malloc gets some blocks from sbrk() and others from mmap() internally
[21:00:04] <seb_kuzminsky> i'll mail out what i have so far, then go afk for a bit
[21:00:13] <jepler> by disabling this behavior, whatever is faulted in by the big allocation will be used for future allocations, large or small
[21:00:27] <jepler> I don't know if the allocator is really that simple, but it's a nice story
[21:00:36] <jepler> but in any case, we don't care too much, because we never allocate memory in realtime
[21:00:56] <jepler> that's part of the hardening code I copied from ubc; I think they copied it from michael buesch.
[21:01:13] <seb_kuzminsky> oh, humm, haw, ok
[21:01:15] <seb_kuzminsky> strange
[21:01:41] <seb_kuzminsky> err, that idiom (mlockall, malloc, free, now that memory's mine) is new to me and i'm not sure i believe it
[21:01:44] <seb_kuzminsky> [citation needed]
[21:01:54] <seb_kuzminsky> bbl
[21:02:20] <jepler> so it looks like the actual problem with the parport reset locking up may be that my rdtsc result is being truncated to 32 bits .. ow
[21:05:00] <jepler> so the consequence of running a realtime program that stuck at 100% CPU was
[21:05:03] <jepler> Jul 5 20:13:01 rat kernel: [13851.032009] INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=15002 jiffies)
[21:05:21] <jepler> and the system remained usable. I could not debug the process, but I could "kill -9" it.
[21:05:30] <jepler> if this was a 1-thread system it would probably have been otherwise
[21:05:34] <cradek> that's wonderful
[21:12:38] <jepler> ah, we've always been using rdtsc wrong on amd64 in userspace.
https://www.technovelty.org/c/reading-rdtsc-on-amd64.html
[21:24:39] <jepler> (gdb) p rtapi_get_clocks()
[21:24:40] <jepler> $9 = 17974369864526
[21:24:40] <jepler> (gdb) p $9 >> 32
[21:24:40] <jepler> $10 = 4184
[21:24:47] <jepler> yay, now my tsc doesn't wrap around once every two seconds or so
[21:25:00] <jepler> also, yay, attaching with gdb gives: Unexpected realtime delay on task 0
[21:56:39] <jepler> 115 files changed, 4360 insertions(+), 3973 deletions(-)
[21:56:48] <jepler> rtos-uspace is getting bigger all the time
[21:57:16] <jepler> compared to on the 28th:
[21:57:16] <jepler> 93 files changed, 4146 insertions(+), 2251 deletions(-)
[21:58:33] <seb_kuzminsky> just ran my bridgeport with rtos-uspace-apis, homed it, ran some mdi g0 commands, all that simple stuff worked perfectly
[21:59:01] <jepler> seb_kuzminsky: cool, that's two machines it's moved
[21:59:20] <jepler> I clocked a lot more deletions than insertions in the last week, though, so that's gotta be good
[21:59:20] <seb_kuzminsky> cradek probably moved max more than i just did
[21:59:29] <jepler> max doesn't have to move very far
[21:59:33] <cradek> it's safer to move max
[21:59:48] <cradek> worst that can happen is the table falls off
[21:59:56] <jepler> .. and hits you right on the foot
[22:17:32] <jepler> > Mention of dark matter is made in some video games and other works of fiction. In such cases, it is usually attributed extraordinary physical or magical properties. Such descriptions are often inconsistent with the properties of dark matter proposed in physics and cosmology.
[22:30:46] <skunkworks_> still running (24+ hours so far)
http://electronicsam.com/images/KandT/testing/stillrunning.png
[22:32:54] <skunkworks_> logger[psha]_:
[22:32:54] <logger[psha]_> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-07-06.html
