#emc-devel | Logs for 2009-02-27

Back
[00:00:32] <jepler> maybe this is equivalent to what you already said about estimating velocity, but I notice that at constant speeds it's always a very small amount (maybe .01%?) below the input frequency of the freqgen I'm driving it with
[00:01:05] <jepler> e.g., .7499625 and .7499906 are the two velocity outputs I see when driving with a stepgen of velocity 0.75
[00:02:53] <jepler> bbl me too
[02:54:15] <cradek> deadline is sure coming up fast...
[03:02:54] <jepler> seems that way
[03:03:58] <cradek> wish I could figure out the halscope problems
[03:04:09] <cradek> do you have any insight that might help?
[03:04:24] <jepler> which halscope problem?
[03:04:31] <cradek> it crashes
[03:04:58] <cradek> gtk assertion warnings and then sometimes sig11 deep in gtk goop with bogus backtrace
[03:05:04] <cradek> (d. garrett is getting it)
[03:05:32] <cradek> I've also seen it crash occasionally - I think we all have?
[03:06:46] <cradek> we were working on it last night ~ 10-11pm
[03:08:13] <cradek> on #emc
[03:14:32] <jepler> ugh
[03:55:48] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/scope.c:
[03:55:48] <CIA-2> EMC: Fix valgrind 'conditional jump'' diagnostics during roll mode
[03:55:48] <CIA-2> EMC: make sure the entire display buffer is zero'd out, because in roll mode not all samples may be initialized
[03:56:09] <jepler> (I'm nearly certain this has nothing to do with dgarr's crashing bug)
[12:59:38] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/machining_center.lyx: remove duplicate info on coordinate system
[13:09:51] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/ (coordinates.lyx main.lyx): clean up
[15:36:18] <jepler> oh, hm -- keystick has a huge problem. It does "all kinds of stuff" in a signal handler
[15:36:50] <jepler> this eventually causes programs to deadlock e.g., because the interrupt happens while malloc holds a mutex, then the signal handler calls malloc or free
[15:37:04] <jepler> posix defines that you can basically do nothing useful in a signal handler
[15:37:18] <cradek> it mallocs/frees in a signal handler?
[15:38:56] <jepler> it does everything in a signal handler
[15:39:03] <cradek> ouch
[15:39:16] <jepler> makes calls to ncurses, sends nml messages, and so on
[15:39:32] <jepler> pretends to make "key up" events
[15:39:33] <cradek> what does it do *outside* the signal handler?
[15:40:38] <jepler> makes calls to ncurses, sends nml messages, and so on
[15:42:46] <cradek> ok yeah, then that's not good.
[15:44:54] <cradek> libnml/buffer/shmem.cc 507: SHMEM: Can't take semaphore
[15:45:09] <cradek> I got a problem too by just jogging for a while
[15:46:18] <jepler> cradek: that traceback is consistent with the freeze I saw
[15:46:28] <cradek> oh, ok
[15:46:29] <jepler> it's in the middle of something, then the signal handler, then some other stuff
[15:46:41] <cradek> I didn't know you saw it break
[15:48:21] <jepler> yes, in valgrind
[15:58:23] <cradek> in the main loop, you could getch() in no-delay mode, and if there is no key waiting, update if it's been a while since the last update
[15:58:41] <cradek> I don't see why the sigalarm scheme is needed
[15:59:32] <jepler> yes I'm working on that just a bit
[16:00:05] <cradek> heh, it must be the obvious fix then
[17:01:47] <jepler> except I broke it -- jogging doesn't work right anymore
[17:03:16] <LawrenceG> emc-devel bookmark
[17:03:44] <jepler> logger_dev: bookmark
[17:03:44] <jepler> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-02-27.txt
[17:04:07] <cradek> I looked at the continuous jog stuff and didn't come away from it with anything but a general fealing of unease
[17:05:24] <jepler> oh I've already had that
[17:06:19] <LawrenceG> thanks
[17:08:07] <jepler> cradek: did you modify your keystick yet? If not, can you tell me if this crashes for you on unmodified keystick? keystick -ini axis_9axis.ini -dump xxx
[17:08:17] <jepler> (while axis_9axis.ini is actually running, of course)
[17:10:16] <cradek> doesn't crash, I get a blank window.
[17:10:33] <cradek> get numbers when I type
[17:10:50] <cradek> q exits
[17:10:51] <jepler> ok, hmm
[17:12:34] <jepler> ah, it must be printing the ncurses key code for keys
[17:16:40] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/keystick.cc:
[17:16:41] <CIA-2> EMC: fix a hang seen in keystick, possibly the same as a problem reported by twice2
[17:16:43] <CIA-2> EMC: POSIX forbids most things to be done in signal handlers, so get rid of the
[17:16:45] <CIA-2> EMC: SIGALRM handler in favor of non-blocking getch() which calls an idle function
[17:16:47] <CIA-2> EMC: when no character is received.
[17:17:03] <cradek> whee
[19:26:03] <cradek> huh, M Buesch's problem is sure puzzling
[19:30:05] <jepler> which problem?
[19:31:38] <cradek> see the list
[19:33:21] <jepler> argh
[19:33:21] <jepler> [1180731.969886] kernel BUG at /build/buildd/linux-2.6.24/mm/rmap.c:631!
[19:33:52] <jepler> [1180731.970222] Fixing recursive fault but reboot is needed!
[19:33:54] <cradek> wtf is that
[19:35:47] <jepler> that's my system acting flaky again
[19:37:52] <jepler> seems to be this (whatever it is, no resolution of it in that thread): http://lkml.org/lkml/2008/2/17/281
[19:44:26] <jepler> anyway, the process that went wrong is my spam filter and it must have lost me some e-mail because I don't have Michael Buesch's message or your reply (gmane does)
[19:44:56] <cradek> bleh.
[19:45:14] <cradek> I'll make you a good deal on a P3 with dapper on it
[19:46:08] <jepler> heh
[19:46:15] <jepler> don't tempt me
[19:46:49] <cradek> dual P3?
[19:47:06] <cradek> nah, that's just asking for trouble
[19:53:57] <jepler> the bright side is that it looks like no mail was lost -- procmail or something was rate-limiting delivery while this problem (which started around 10AM) was going on
[19:54:39] <jepler> so I'll just have to bounce it when I get home and all will be well
[20:45:35] <jepler> sometime in the next few hours I'll be rebooting the machine that hosts CVS. The downtime should be only a few minutes.
[20:48:36] <cradek> M Buesch's problem is on x86_64
[20:50:24] <alex_joni> and with gcc-4.3.2
[20:52:43] <cradek> I'm glad he could debug it
[21:04:09] <alex_joni> yup
[22:52:28] <jepler> cvs and I will be back in just a few minutes
[22:58:51] <jepler> and I think we're back..