Back
[08:48:07] <skunkworks_> cradek: are you around?
[08:49:11] <skunkworks_> I think the program that was posted on the forum as found another issue.. Could you double check for me?
[08:50:05] <skunkworks_> G61
[08:50:06] <skunkworks_> G1 X -850 F6000
[08:50:08] <skunkworks_> G0 X -325 ; bug appears here
[08:50:09] <skunkworks_> G1 X -275 F300
[08:50:11] <skunkworks_> G0 X -52
[08:50:12] <skunkworks_> G1 X -2 F300
[08:50:14] <skunkworks_> M2
[08:50:36] <skunkworks_> after the f6000 - it runs the rest of the program at G0 speeds.
[08:51:02] <skunkworks_> and it doesn't exact stop
[08:51:19] <skunkworks_> unless I am doing something goofy
[08:54:35] <skunkworks_> I wonder if co-linear line segments are automatically combined.. with no regards to feed
[08:57:37] <skunkworks_> drat - pre-cab works as expected..
[09:05:24] <skunkworks_> huh - it does work as expected with g64Q0
[09:08:26] <skunkworks_> huh - then G61 works as expected.. It is almost like when you first start linuxcnc - Q is non-zero.. which effects G61
[09:08:33] <skunkworks_> behavior
[09:09:06] <skunkworks_> wait - I was running pre-cab..
[09:09:09] <skunkworks_> scratch that
[09:10:41] <skunkworks_> nope g64q0 doesn't help..
[09:37:30] <skunkworks> rob is going to look at it
[09:39:14] <pcw_home> A bit too aggressive combining the lines?
[09:40:18] <skunkworks> he said.. Good find, I'll take a look at the tangent-segment code. Likely I forgot a check for blend state in there.
[11:12:55] <skunkworks_> rob did bring up an interesting point - there should be a difference between g61 and g61.1.. Exact path vs exact stop... Exact path - may not have to stop at the end points to have an 'exact path' vs exact stop which would stop at every end point...
[11:18:12] <cradek> if he feels like making those differences work, it would be utterly defensible
[11:21:26] <skunkworks> I am totally confused now.. The ini file that I was using - with the forum axis settings for x and y - doesn't exact stop for the above program.. but if I go back to my normal test config - it does.
[11:22:18] <skunkworks> and it should anyway - because it is G0 to G1 and G1 to G0 transistions..
[11:22:49] <cradek> I noticed his accel and velocity were the same (for X) which I think means you won't get up to full speed unless your move takes 2 seconds or more... if your config is different you might get very different blending/joining behavior
[11:23:07] <cradek> I was going to dig into this but if rob's on it he'll be able to do it a lot more efficiently :-)
[11:37:37] <skunkworks> I should say - it doesn't exact stop - but it does slow down to 300mm/m.
[13:10:03] <skunkworks_> so - it seems like if the acceleration for the axis is low enough - it skips over the slow section...
[14:45:18] <skunkworks_> axis acceleration set to 3
[14:45:29] <skunkworks_> http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-06-17%2014:16:14.png
[14:45:37] <skunkworks_> axis acceleration set to 20
[14:45:56] <skunkworks_> http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-06-17%2014:18:54.png
[14:46:12] <skunkworks_> ^for the above program
[15:36:15] <cradek> hmm, upon starting master on wheezy/3.4.55-rtai-2:
http://timeguy.com/cradek-files/emc/tpSetTermCond.jpg
[16:02:46] <seb_kuzminsky> cradek: it's weird that the pde has the PS bit cleared, but the pte is 0
[16:08:27] <cradek> I don't know what that means
[16:09:09] <cradek> do you know how to disassemble a .ko? gdb doesn't recognize it...
[16:09:39] <cradek> +0x4 is awfully early in the function, isn't it
[16:11:00] <cradek> I sent this to -devel
[16:12:06] <micges> cradek: does it crash in sim mode?
[16:12:25] <cradek> yes running sim/axis/axis crashes the same way
[16:12:51] <micges> I mean --enable-simulator
[16:13:33] <cradek> nope, that runs fine
[16:13:53] <cradek> ... but let me try on the same machine for good measure
[16:14:52] <cradek> (wonder if it would be possible to run sim motmod in valgrind)
[16:15:05] <cradek> I guess it would be rtapi_app
[16:16:16] <seb_kuzminsky> cradek: the page map looks screwed up to me
[16:17:45] <cradek> yes an --enable-simulator build runs fine
[16:18:30] <cradek> seb_kuzminsky: what can I do to help find the problem?
[16:18:42] <seb_kuzminsky> is it repeatable when compiled with rtai?
[16:19:27] <cradek> I did it twice, once with my 5i25 config and once with sim/axis/axis
[16:19:36] <cradek> then I cleaned and rebuilt for -sim, which might have been a mistake
[16:20:00] <seb_kuzminsky> it would be helpful to inspect the page table at physical address 0x016a6000, but that probably requires instrumenting the kernel
[16:20:10] <jepler> I typed the hex code into a .s file and built it, but the disassembly doesn't make much sense so I probably fat-fingered it
[16:20:41] <jepler> it starts out sane-ish: test %eax,%eax / mov %eax, %ecx / (faulting instruction) fldl (%edi) / je tpSetTermCond+0x27
[16:21:32] <jepler> but in what calling convention would tolerance be pointed at by %edi? or is it some other double?
[16:22:21] <jepler> to the extent that the contents of %edi and the faulting address are the same, it sort of makes sense
[16:25:43] <cradek> yep, reproduceable after clean/rebuild
[16:25:48] <seb_kuzminsky> oh good
[16:28:24] <cradek> unfortunately, I need to run for about 4h
[16:28:56] <seb_kuzminsky> have a good run ;-)
[16:28:59] <cradek> this is weird. surely others are running master on rtai (but I guess maybe not 3.4.55)
[16:29:31] <cradek> heh, if I had to run for 4h you would probably not hear from me again.
[16:29:40] <seb_kuzminsky> we know runtests passes on precise with 3.4.55-rtai, but maybe that part of the code isn't exercised
[16:30:19] <cradek> hmm, I should try them
[16:31:38] <cradek> linuxcncrsh test crashes
[16:31:48] <seb_kuzminsky> when you get back from your run & subsequent defibrillation, try instrumenting tpSetTermConddoh
[16:31:51] <seb_kuzminsky> doh
[16:32:03] <seb_kuzminsky> might be time for memtest ;-)
[16:33:09] <jepler> when I build that code, I get fldl 0x8(%esp) instead of fldl(%edi)
[16:33:19] <seb_kuzminsky> wait, is this one of those computers you pulled out of a dumpster and/or thrift store? i notice it's got a crt...
[16:33:20] <jepler> dd 44 24 08 vs dd 07
[16:33:32] <seb_kuzminsky> 8(%esp) makes more sense to me
[16:33:41] <seb_kuzminsky> that's on 32-bit, right?
[16:33:53] <jepler> .. but that doesn't make sense either, because the subequent instruction is adding -1 via leal in both cases
[16:34:12] <seb_kuzminsky> 4 for the pointer, then 4 for int cond, then the double tolerance
[16:34:13] <jepler> (this is building by hand for userspace, so gcc flags are going to be different)
[16:35:24] <cradek> will run memtest86 while I'm gone
[16:35:47] <cradek> this machine runs 2.6/5i25 fine
[16:36:03] <cradek> it's good hardware as far as I know
[16:36:21] <cradek> now really, bbl
[16:37:02] <seb_kuzminsky> wait! how much ram does it have?
[16:37:06] <seb_kuzminsky> heh
[16:57:54] <cradek> 6 GB
[16:59:31] <cradek> seb_kuzminsky: ^
[17:06:09] <seb_kuzminsky> hmm ok
[18:48:36] <skunkworks_> I have only compiled it on the realtime 10.04...
[18:51:19] <skunkworks_> I know there have always been differences between realtime and simulator builds as far as bugs
[21:22:37] <cradek> seb_kuzminsky: many memtest86+ passes show no troubles
[21:23:48] <cradek> maybe tomorrow I'll try to put on my wizard hat and run rtapi_app under valgrind
[21:25:04] <cradek> I guess maybe I could bisect it, but it would be very time-consuming with reboots, and I'm not too sure that most of the intermediate TP commits are runnable
[21:25:26] <cradek> I guess this is on startup, so it doesn't matter if they really work well at all, it only has to build and run
[21:27:07] <cradek> I can loadrt/addf and run motmod
[21:29:20] <Jymmm> hey cradek!
[21:29:34] <cradek> hi
[21:29:55] <Jymmm> cradek: you get my PM by chance?
[21:30:33] <cradek> ni
[21:30:35] <cradek> no
[22:24:34] <seb_kuzminsky> https://www.youtube.com/watch?v=zIV4poUZAQo
[22:58:19] <seb_kuzminsky> cradek: the old dell that runs my bridgeport is running precise with 3.4.55-rtai-2, and it runs master just fine
[23:04:09] <cradek> odd. but clearly there is something wrong with what I have here...
[23:05:19] <cradek> miscompiled?
[23:05:42] <cradek> this is not a pae kernel, so I doubt it's the amount of memory
[23:14:57] <cradek> seb_kuzminsky: which master did you try?
[23:20:06] <cradek> SET_TERM_COND is about the 72nd message motmod gets on a normal startup
[23:23:14] <seb_kuzminsky> current tip-of-branch
[23:23:51] <seb_kuzminsky> and yeah, that's a painfully slow bisect
[23:24:29] <seb_kuzminsky> i'm imagining an X10 controller power outlet and a second machine that orchestrates the test
[23:24:46] <seb_kuzminsky> and reboots the victim computer if it stops responding to pings when you trigger the bug
[23:25:27] <seb_kuzminsky> i'm on 377f171e
[23:27:13] <cradek> ok, same as me
[23:27:16] <cradek> just checking...
[23:28:48] <seb_kuzminsky> can you try instrumenting tpSetTermCond to print out all the addresses it's going to try to touch?
[23:30:05] <cradek> how can I get messages to the console or anywhere else useful?
[23:30:18] <cradek> hm, I could replace it with "return"
[23:30:31] <seb_kuzminsky> you're in the kernel right? printk should work?
[23:31:12] <cradek> I'm in X and I don't know what magic gives me a console when it panics
[23:31:26] <cradek> I can try
[23:33:48] <seb_kuzminsky> i wonder if the text-mode configs trigger it? seems like they should
[23:34:01] <seb_kuzminsky> then you could run keystick from a text-mode vt
[23:34:12] <cradek> or halui-only
[23:34:13] <cradek> good idea
[23:34:27] <cradek> but tomorrow...
[23:36:08] <seb_kuzminsky> yep
[23:36:31] <seb_kuzminsky> i'm going to test one more computer, then i'm going to the hackspace to work on the new rtai kernel modules packaging
[23:36:46] <cradek> still tonight? jeez
[23:38:47] <seb_kuzminsky> its an hour earlier here
[23:38:55] <cradek> whelp, adding a return at the beginning of tpSetTermCond actually does let it all run
[23:39:04] <cradek> I did not expect that
[23:41:08] <seb_kuzminsky> huh, strange
[23:41:24] <seb_kuzminsky> my second test-computer runs precise with 3.4.55-rtai-2 too, it also runs master fine
[23:41:41] <cradek> gcc version 4.7.2 (Debian 4.7.2-5)
[23:41:53] <seb_kuzminsky> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
[23:42:55] <seb_kuzminsky> well i'm off, more debugging tomorrow!
[23:43:01] <cradek> me too, goodnight
