Back
[08:43:13] <jepler> zlog:
[10:00:41] <jepler> pcw_home: I reproduced the crash
[10:00:54] <jepler> unfortunately the debugger fails to furnish line-number information
[10:01:01] <jepler> Program received signal SIGSEGV, Segmentation fault.
[10:01:01] <jepler> [Switching to Thread 0x7f92391d6700 (LWP 4667)]
[10:01:01] <jepler> 0x00007f9237695f9e in ?? () from /usr/lib/linuxcnc/modules/hostmot2.so
[10:01:44] <pcw_home> Yeah Didnt yet try on PCI (need to buld a resolver/DPLL config)
[10:02:26] <jepler> ah there it is
[10:02:28] <jepler> 0x00007fc3947abf0e in hm2_stepgen_write (hm2=hm2@entry=0x19d2260)
[10:02:28] <jepler> at hal/drivers/mesa-hostmot2/stepgen.c:436
[10:02:28] <jepler> 436 if (*hm2->stepgen.hal->pin.dpll_timer_num != hm2->stepgen.written_dpll_timer_num) {
[10:04:53] <jepler> I should have a patch to test in 5
[10:05:23] <pcw_home> is it a bug with configs with dpll but no stepgens?
[10:05:39] <pcw_home> Didnt think of that possibility
[10:07:23] <jepler> the pin ...stepgen.timer-number doesn't exist but the C code dereferences the associated pointer pin.dpll_timer_num
[10:08:01] <pcw_home> oops
[10:09:34] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-resolver-no-stepgen eb5f2c7 06linuxcnc 10src/hal/drivers/mesa-hostmot2/stepgen.c hostmot2: don't crash with DPLL and no stepgen * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eb5f2c7
[10:09:38] <pcw_home> All the configs ive been testing with have had stepgens
[10:09:39] <pcw_home> I guess I need test with things missing insead of just adding more modules
[10:10:21] <pcw_home> i wonder if the necoder module has the same issue
[10:11:45] <jepler> hostmot2 encoder.c doesn't have any references to pll
[10:11:50] <jepler> abs_encoder has
[10:12:19] <jepler> // If there is no dpll to link to, then we export the trigger function.
[10:12:22] <pcw_home> ahh maybe thats only in master
[10:12:57] <jepler> oh yes, I'm looking in 2.7.
[10:13:16] <pcw_home> I tested dpll encoder sampling it so I know its somewhere...
[10:15:20] <jepler> maybe I'm not grepping for the right things, but I don't see it in master either
[10:15:55] <pcw_home> maybe it was only a patch
[10:31:56] <jepler> if so it would be good to dig it back up and get it in master
[10:32:11] <jepler> or maybe even 2.7 if it's important for ethernet performance
[10:38:06] <pcw_home> Yeah I though it was merged :-(
[11:22:17] <jepler> huh clang (3.5) gets 1/3 the performance of gcc (4.9) on this code. but clang 3.7 is closer, only 10% slower
[11:28:11] <pcw_home> Thats a huge speed change between versions
[12:10:07] <jepler> I think I'm hitting this clang optimizer shortcoming
https://llvm.org/bugs/show_bug.cgi?id=17332
[12:17:47] <jepler> which as the last comment says is basically fixed now
[12:34:31] <KGB-linuxcnc> 03Jeff Epler 052.7 21a083f 06linuxcnc Merge branch 'jepler/hm2-eth-packetreduction' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=21a083f
[12:34:31] <KGB-linuxcnc> 03Jeff Epler 052.7 35cc7e2 06linuxcnc Merge branch 'jepler/hm2-resolver-no-stepgen' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=35cc7e2
[12:34:31] <KGB-linuxcnc> 03Jeff Epler 052.7 f3fc602 06linuxcnc Merge branch 'jepler/elbpcom' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f3fc602
[12:34:32] <KGB-linuxcnc> 03Jeff Epler 052.7 e868776 06linuxcnc 10docs/man/man9/hm2_eth.9 hm2_eth: it's our elbpcom program now * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e868776
[13:02:34] <pcw_home> Yay!
[13:11:36] <skunkworks> Neat!
[13:24:00] <pcw_home> elbpcom 01D91A00025A01C92800000001420001
[13:24:02] <pcw_home> to set the 7i 80/92/93/76e LEDs to hostmot2 permanently
[17:08:42] <seb_kuzminsky> pcw_home: that thing that jeff just fixed, was that the 2.7 blocker that you were telling me about before?
[17:10:27] <pcw_home> Yeah, it pretty much broke using index with hm2_eth so was serious (as was the just discovered no stepgen but dpll bug)
[17:11:46] <pcw_home> I'd like to get the encoder sampled by dpll patch in but I may be optimistically remembering it as having been done
[17:11:48] <seb_kuzminsky> ok, so the original problem is fixed, but there's a new thing with stepgen but no dpll that needs to be fixed before 2.7, is that right?
[17:12:10] <pcw_home> Jeff fixed that also
[17:12:22] <seb_kuzminsky> oh wow
[17:12:27] <seb_kuzminsky> the man is on fire today
[17:12:29] <pcw_home> the probal was dpll but no stepgen
[17:12:35] <pcw_home> problem
[17:12:57] <pcw_home> yeah lots of fixes
[17:18:23] <pcw_home> I have a lot of time in hm2-testing (more that a year 24/7) but not much breadth if configs
[17:18:40] <pcw_home> hm2-eth testing I mean
[17:19:57] <seb_kuzminsky> that's how testing goes, often times
[17:20:18] <seb_kuzminsky> thus software works well in certain narrow code paths, and is buggy outside those well-tested code paths
[17:20:37] <pcw_home> well its a lot more work to try different configs than just rack up hours
[17:22:10] <seb_kuzminsky> it sure is
[17:22:35] <seb_kuzminsky> at my dayjob we have a roughly 50/50 split between folks writing product code and folks writing new tests of the product
[17:23:52] <seb_kuzminsky> and we still find tons of bugs when we extend the breadth of testing
[17:24:15] <pcw_home> Yeah I can easily see that
[17:25:37] <pcw_home> I had ablind spot where I thought the problem was likely a combination of modules,
[17:25:38] <pcw_home> not hidden assumptions in the code that a module is always there
[17:32:01] <pcw_home> I didn't expect that the most common problems people have with hm2_eth are basic network setup related
[18:08:47] <skunkworks> I have done it before and it still takes me a couple of tries to get it right
[18:14:17] <pcw_home> maybe some kind of a setup script is needed
[19:55:38] <mozmck> pcw_home: I may be able to help with a setup script
[19:55:47] <mozmck> Something like that is on my list to do.
[21:09:24] <pcw_home> I have changed the init scripts here so all cards will come with 10.10.10.10 EEPROM IP address
[21:11:00] <pcw_home> I wonder if the bootp option would help find the card (which entN its connected to)
[21:12:39] <pcw_home> eth(n) I mean
[21:18:29] <seb_kuzminsky> pcw_home: could you use mdns? then the card could autoconfigure, and you could refer to it by name instead of address
[21:18:46] <seb_kuzminsky> http://en.wikipedia.org/wiki/Multicast_DNS
[21:18:48] <seb_kuzminsky> bbl
[21:22:04] <jepler> pcw_home: if you are going to do 10.10.10.10, then we should change linuxcnc, which defaults to 192.168.1.121
[21:22:26] <pcw_home> mdns looks pretty simple
[21:22:40] <jepler> I agree the initial setup is terrible, even though I carefully wrote it all down in that manpage that's not going to help users, particularly beginning users
[21:23:00] <jepler> more of it *could* potentially be semi-hardcoded in hm2_eth.c too
[21:23:34] <pcw_home> Yeah , (I've come to realize) the 192.168.1.121 is really just for for recovery
[21:24:03] <pcw_home> or configurattion on a normal local network
[21:24:03] <jepler> actually it should be an ipv4 link-local address
[21:24:16] <jepler> not sure
[21:24:34] <jepler> let me rephrase that to, we should explore whether it should be a link-local address
[21:24:39] <pcw_home> mdns looks good for jumper option 3
[21:26:54] <jepler> with a link-local address + mdns you would just say loadrt hm2_eth ...iface=eth1...
[21:28:22] <jepler> setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, "eth1", strlen("eth1"))
[21:29:00] <pcw_home> yeah that would be better (plus I now have a whole ~2 K of code space free!)
[21:29:25] <jepler> and probably SO_DONTROUTE would be good to add
[22:36:59] <Tom_itx> damn storms knocked the logbot off
[22:37:28] <mozmck> I was thinking of something to ping each iface and look for a response from the mesa card.