Back
[14:49:59] <cradek> KimK: are you bringing your card and encoders to workshop?
[15:06:21] <mozmck_work> logger_dev: bookmark
[15:06:21] <mozmck_work> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-05-28.txt
[15:29:01] <JT-Work> mozmck_work: I gave 10.04 another try and crashed somewhere I forget exactly... but I think it was the rtai part
[15:29:58] <mozmck_work> hmm, it crashed trying to run emc?
[15:30:52] <JT-Work> trying to install
[15:31:21] <mozmck_work> huh, did you have the rtai kernel installed first?
[15:31:31] <JT-Work> got vertical lines on screen of different colors about 1/8" wide and a big square for the mouse pointer
[15:31:53] <mozmck_work> oh, weird.
[15:32:01] <JT-Work> rtai was about the 4 thing I think
[15:32:28] <JT-Work> only way I could recover was to install 10.04 over again
[15:32:30] <mozmck_work> it did that just trying to install the rtai packages?
[15:32:32] <micges> mozmck_work: hi
[15:32:37] <JT-Work> yes
[15:32:41] <mozmck_work> hi micges
[15:32:44] <micges> your packages works fine
[15:33:09] <micges> rt works fine, just jitter is somewhat large
[15:33:28] <mozmck_work> JT-Work: now that's really odd.
[15:33:41] <JT-Work> Rob had no problems using your packages
[15:34:27] <mozmck_work> micges: is it a single-core computer? On the single-core I tried the latency was actually somewhat better than 8.04 on the same computer.
[15:35:13] <mozmck_work> but I haven't given it a workout on a multicore yet.
[15:35:23] <micges> intel 6500 dula core
[15:35:41] <mozmck_work> ok. is that even using isolcpus?
[15:35:58] <micges> no
[15:36:46] <mozmck_work> It would interesting to see how much that helps.
[15:36:49] <micges> I'm planning gather info about jitter decreasing on weekend and start testing on monday
[15:37:05] <micges> mozmck_work: many thanks for packages
[15:37:39] <cradek> mozmck_work: were are your latest packages for lucid? I have an old machine to try them on.
[15:37:43] <mozmck_work> JT-Work: I don't know what to say on your install problem. Were you running my kernel when you installed the problem package?
[15:38:01] <mozmck_work> cradek:
http://www.linuxcnc.org/mozmck
[15:38:09] <JT-Work> no was I supposed to?
[15:38:22] <mozmck_work> JT-Work: no, I was just wondering.
[15:39:07] <JT-Work> I started at the headers and installed all down to rtai one after another
[15:39:39] <mozmck_work> I can't think of any reason it would do that at all. maybe someone else will have an idea.
[15:51:29] <micges> cradek: I think according to docs this code should return error:
http://www.pastebin.ca/1873400
[15:52:55] <micges> (it doesn't on v2.4 branch)
[15:54:30] <jepler> I agree that on the first line #<name> is undefined in the scope. Where in the docs does it say that this is an error condition?
[15:55:09] <micges> jepler:
http://www.linuxcnc.org/docview/html//gcode_overview.html#sub:Named-Parameters
[15:55:53] <jepler> which part of that says emc will signal an error in this case?
[15:56:37] <jepler> there are gcode mistakes that simply have undefined results, as opposed to being diagnosed as errors. I don't see that the docs promise this error is diagnosed.
[15:59:23] <micges> imo variable is undefined on reading
[16:01:00] <micges> maybe I'm wrong, just learning some subroutines bahaviour
[16:01:02] <jepler> I think the docs don't say that, and the implementation clearly returns 0.0 in this case.
[16:01:15] <jepler> interp_read.cc Interp::find_named_param
[16:01:39] <micges> so we should simply add this to docs
[16:02:47] <jepler> I'm not sure what we should do.
[16:03:04] <jepler> the docs don't specify what happens in this case, but maybe the implementation isn't the best one.
[16:15:01] <jepler> there are 4 alternatives: do nothing; make the documentation explicitly say that the value of an undefined named parameter is 0.0; make it say that the result of using the value of an undefined named parameter is undefined; or make it an error and document that it's an error.
[16:15:38] <jepler> the first three mean that we don't have to change any code, but the second one forecloses making it an outright error in the future
[16:16:15] <jepler> the downside to doing the last one is that there is an unknown amount of code that works OK and depends on the current behavior
[16:17:18] <JT-Work> the upside to the last one is faster debugging perhaps when you do have an undefined variable that you assumed you had defined
[16:17:57] <jepler> option 5 or 6: like option 1 or 3 but also display a message about the detected problem (maybe even saying it will become an error in the future)
[16:18:54] <jepler> but I don't think we have a non-fatal error facility besides what (MSG,) does and so that message probably won't be displayed if for instance the subsequent motion exceeds soft limits
[16:19:14] <jepler> (since execution will stop as soon as the first limit-exceeding move is interpreted)
[16:21:42] <jepler> * jepler just spent a good 10 minutes trying to resolve this error: Makefile:30: missing separator. Stop.
[16:22:00] <jepler> I unintentionally ended up with a 9-year-old version of make (3.62) on my PATH before /usr/bin/make
[16:24:19] <micges> jepler: we shuld ask others what could we do
[16:24:24] <JT-Work> I would have spend 10 days and never found it :)
[16:25:40] <jepler> JT-Work: you wouldn't have a 9-year-old make, either
[16:27:29] <jepler> here's the patch to make it an error:
http://emergent.unpy.net/files/sandbox/0001-Don-t-let-a-named-parameter-error-pass-silently.patch
[16:28:15] <jepler> it breaks runtests, because flowsnake uses the 'undefined is 0.0' behavior.
[16:29:20] <jepler> or maybe the patch is mistaken; the line where it blows up is assigning to the parameter. so forget my patch..
[16:30:24] <micges> jepler: we should have place to put those problems to all developers to see
[16:30:38] <micges> I mean problems like this
[16:33:29] <cradek> mozmck_work:
http://timeguy.com/cradek-files/emc/lucid-on-asus-p3-1200.errors.txt
[16:35:12] <jepler> we have a choice between an SMP kernel or supporting machines without APIC. [ 68.375908] RTAI[hal]: ERROR, LOCAL APIC CONFIGURED BUT NOT AVAILABLE/ENABLED.
[16:35:43] <cradek> that makes me very sad
[16:36:26] <cradek> so on my dual P3, it might still work?
[16:37:01] <jepler> what's /proc/cpuinfo look like on that system?
[16:37:09] <cradek> scroll down
[16:37:29] <cradek> oh you mean on the smp one (sorry)
[16:37:38] <cradek> let me see if it's on
[16:39:00] <cradek> cpuinfo on dual p3:
http://pastebin.ca/1873414
[16:39:31] <jepler> huh I expected to see apic in there
[16:39:39] <cradek> I see it
[16:39:50] <jepler> oh there it is
[16:39:58] <jepler> can you post full dmesg from the non-working system?
[16:40:09] <cradek> sure
[16:41:42] <cradek> http://timeguy.com/cradek-files/emc/asus-p3-1200-dmesg.txt
[16:42:07] <jepler> [ 0.000000] Local APIC disabled by BIOS -- you can enable it with "lapic"
[16:42:13] <jepler> try putting 'lapic' on kernel commandline
[16:42:17] <cradek> I don't think anything scrolled off, but I can reboot to make sure
[16:42:20] <cradek> ok
[16:45:31] <cradek> locked memory error now... one sec
[16:46:53] <jepler> intel documentation says that everything pentium-75 and up has (L)APIC but the internet suggests that it was unreliable or disabled in hardware in the early days.
http://lkml.indiana.edu/hypermail/linux/kernel/0008.2/0161.html
[16:47:10] <cradek> it had placed "* hard memlock 20480", I changed it to "* - memlock 20480" according to the wiki page
[16:48:58] <cradek> yay, latency test runs
[16:50:16] <cradek> ha, only 700,000 ns latency when starting glxgears (nvidia binary driver)
[16:50:29] <jepler> ow
[16:51:25] <cradek> it was 8000 before that
[16:51:31] <cradek> trying to change to vesa...
[16:53:53] <cradek> huh, changing to vesa gave me a 2048x1536 screen by default
[16:54:18] <cradek> ... need a bigger mouse pad
[16:54:49] <Jymmm> s/bigger/faster/
[16:57:35] <JT-Work> I end up using my leg for a mouse pad when I'm at a customers plant
[17:01:14] <jepler> from what I can tell, Windows only supports ACPI on APIC systems, and ACPI is mandatory since Vista (2005). So it seems like 2005+ systems shouldn't encounter APIC problems (though maybe some unknown portion of them will need 'lapic' on the kernel commandline)
[17:02:04] <cradek> well I porked my machine (X)
[17:02:15] <cradek> I installed libgl1-mesa-swx11
[17:02:29] <cradek> (and removed nvidia-*)
[17:03:33] <mozmck_work> cradek: so putting lapic on the boot line allowed rtai to load?
[17:04:22] <cradek> yes
[17:04:31] <mozmck_work> A guy on the rtai list had to build a different kernel for an atom board and geode because of this problem. The one had no apic and the other required it or something like that.
[17:05:20] <mozmck_work> interesting.
[17:08:04] <skunkworks> I have an atom 330 I could try to install - this weekend.
[17:49:32] <Dave911> I am pretty sure the Intel 330 board (now obsolete) has an apic
[17:52:36] <Dave911> Mach3 uses the Apic for it's famed parallel port driver. I've been on the email list for Mach3 for years and virtually no one has an issue with a missing apic. Even so, Art did write a driver version that does not require the apic, but again from what I can tell, virtually no one uses it from what I can tell..
[18:27:46] <jepler> well that was a fun puzzle. Suddenly my system had started generating Release files which were broken due to having an extra blank line in the file. It turns out that this behavior went away when I deleted two unintentional dangling symlinks in the repository.
[18:33:13] <JT-Work> I almost understand what you said
[18:44:28] <Dave911> JT-Work: Did I miss a response from you about my file conversion issues ?
[18:44:54] <Dave911> Or are those pesky customers calling you again . ;-)
[18:48:13] <jepler> https://patchwork.kernel.org/patch/37090/
[18:48:21] <jepler> > I wouldn't expect wbinvd to take longer than a ms or two, which
[18:48:21] <jepler> is probably not catastrophic yet.
[19:58:45] <dgarr> m66 is very neat, i think the inclusion of this print is unitended:
http://www.panix.com/~dgarrett/stuff/0001-GET_EXTERNAL_ANALOG_INPUT-printf-message-only-for-IN.patch
[20:14:22] <alex_joni> dgarr: glad you like it, yes it is (unintended)
[20:18:35] <dgarr> alex_joni: it will be useful for fixed-tool ornamental turning like they did 400 years ago:
http://www.getty.edu/art/gettyguide/artObjectDetails?handle=other&artobj=1419&artview=55374
[20:21:28] <alex_joni> hmm.. I wonder how M66 relates to that cup
[20:26:56] <dgarr> external (non gcode) control of lateral (x) feed on a rose engine (xzc)
[20:27:45] <alex_joni> ah
[20:27:58] <alex_joni> you can also do that in HAL
[20:28:05] <alex_joni> but I can understand wh
[20:28:13] <alex_joni> but I can understand why g-code is easier
[20:29:19] <dgarr> yes -- i've been doing joystick offsets in hal, this will allow additional x feed per rev tweaking
[20:29:50] <alex_joni> http://www.pledge.co.uk/pledge_and_aldworth/ref/ch2e.htm <- cool site
[20:31:03] <dgarr> also:
http://ornamentalturning.net/gallery/index.html
[20:32:40] <dgarr> and the some of the best work done today (no cnc):
http://www.ornamentalturners.org/forum/gallery2.php?g2_itemId=6996
[20:57:30] <Dave911> dgarr: So do you run some type of external control program around emc2 and then feed the offset back into it?
[20:59:53] <dgarr> no -- the external offset control is manual from a manual pulse generator or joy stick, it's hard to get the lateral feed right for all conditions, so experimenting is useful.
[21:06:47] <Dave911> ok
[21:36:24] <cradek> mozmck_work: after a reinstall (and not screwing it all up with the nvidia driver) your packages work great after I change the hardlock line from "hard" to "-" and boot with "nolapic" added to the kernel command line
[21:36:37] <cradek> mozmck_work: I played daisy.ngc on stepper/sim and it sounds great.
[21:37:02] <cradek> bbl
[21:48:00] <CIA-1> EMC: 03jepler 07v2.4_branch * r6bd5d1ad9fed 10/src/rtapi/rtai_rtapi.c: Restore default message level
[21:52:58] <dgarr> jepler: not sure you noticed submittal earlier:
http://www.panix.com/~dgarrett/stuff/0001-GET_EXTERNAL_ANALOG_INPUT-printf-message-only-for-IN.patch
[21:58:44] <CIA-1> EMC: 03jepler 07v2.4_branch * r30369b9501e5 10/src/emc/task/emccanon.cc: GET_EXTERNAL_ANALOG_INPUT: printf message only for INPUT_DEBUG
[22:03:27] <jepler> argh, I know there's a program related to my fpga rng on this hard drive, but I can't find it
[22:06:16] <jepler> aha, here it is
[22:22:05] <mozmck-6core> cradek: good to hear! are you using grub2?
[22:24:12] <dgarr> jepler: thanks!
[23:34:57] <cradek> mozmck-6core: I didn't do anything special with grub
[23:35:22] <cradek> er, I meant boot with "lapic", not "nolapic"
[23:37:01] <cradek> I get latency of 21knsec on it running opengl stuff