Back
[00:09:57] <jepler> hi jmkasunich
[00:10:00] <jepler> how's your reinstall?
[00:10:08] <jmkasunich> just burned the cd
[00:10:13] <jmkasunich> md5sum's don't match
[00:10:17] <jepler> argh
[00:10:31] <jepler> CDs are just not reliable media
[00:10:52] <jmkasunich> istr reading something about md5summing cds, like the burn sometimes pads the data, which messes up the sum
[00:11:10] <skunkworks> I have never checked the checksum... Its a wonder my shit runs ;)
[00:17:21] <cradek> hi jmk
[00:17:30] <jmkasunich> hi
[00:17:32] <cradek> jmkasunich: boot it and run the validate there
[00:17:39] <cradek> you usually can't md5 a burnt cd
[00:17:53] <cradek> well you can, but it turns out to not match
[00:18:03] <jmkasunich> I've done it before (and had it match)
[00:18:05] <cradek> they got smart and md5 all the files on it now
[00:18:19] <cradek> "usually"
[00:18:25] <jmkasunich> but IIRC, I needed to use dd to pipe _only_ the exact length of the iso to md5sum
[00:18:45] <cradek> I've read the scsi drives typically were able to do it right, but that's not personal experience
[00:19:37] <jmkasunich> retrying the sum with dd...
[00:21:16] <jmkasunich> I remembered to print the procedure for partitioning and such
[00:21:18] <jmkasunich> http://pastebin.ca/225551
[00:22:55] <jmkasunich> they match!
[00:23:27] <jmkasunich> http://www.troubleshooters.com/linux/coasterless.htm tells how to read only the proper amount of data from the CD and into md5sum
[00:23:45] <jmkasunich> time to reboot!
[00:23:59] <jmkasunich> see you in an hour or two
[01:47:27] <jmkasunich> hi guys
[01:49:02] <cradek> success?
[01:49:09] <jmkasunich> no
[01:49:12] <jmkasunich> network problems
[01:49:23] <jmkasunich> google says maybe acpi related
[01:49:52] <jmkasunich> I get these in dmesg: NETDEV WATCHDOG: eth0: transmit timed out
[01:49:56] <cradek> yuck
[01:50:10] <cradek> yeah that's probably an interrupt problem
[01:50:22] <cradek> is this the magma or normal kernel?
[01:50:32] <jmkasunich> normal dapper kernel
[01:51:20] <cradek> I'm surprised then
[01:51:38] <jmkasunich> searching for that message + ubuntu gets a lot of hits
[01:51:44] <jmkasunich> and a lot of frustrated people
[01:52:07] <cradek> oh it's not particular to one chipset or something?
[01:52:38] <jmkasunich> not sure, haven't compared the details of all the messages
[01:52:48] <cradek> what is yours?
[01:53:05] <jmkasunich> it can't be the hardware, because I'm running breezy on the exact same hw right now
[01:53:13] <jmkasunich> its gotta be the driver or kernel from 6.06
[01:53:22] <cradek> yeah
[01:53:27] <cradek> disappointing
[01:53:34] <jmkasunich> 0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78)
[01:53:47] <jmkasunich> at least thats what breezy thinks
[01:54:35] <cradek> 0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78)
[01:54:41] <cradek> mine's identical and works
[01:54:49] <jepler> https://launchpad.net/distros/ubuntu/+bug/48263
[01:54:51] <jmkasunich> dapper?
[01:54:54] <cradek> yes
[01:55:13] <cradek> magma and normal kernels, never a problem
[01:56:36] <jepler> (apparently this guy in the report is using it in combination with some wireless card, not sure if that's a red herring or not)
[01:57:07] <jmkasunich> he's describing a lockup, I didn't get that
[01:57:21] <cradek> jmkasunich:
http://pastebin.ca/225659 fwiw
[01:57:42] <jmkasunich> how'd you get that?
[01:57:48] <jmkasunich> I got the single line with lspci
[01:57:51] <SWPadnos> the idea of trying the acpi=noirq boot option may help
[01:58:05] <cradek> chris@buster:~$ grep eth0 /proc/interrupts
[01:58:06] <cradek> 193: 4612723 IO-APIC-level eth0
[01:58:21] <cradek> sudo lspci -vv -s 12
[01:58:28] <SWPadnos> jmkasunich, did you use sudo lspci -vvv ?
[01:58:33] <SWPadnos> right :)
[02:01:54] <jmkasunich> mine as detected by breezy is similar but not identical:
[02:01:55] <jmkasunich> 3c3
[02:01:55] <jmkasunich> < Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
[02:01:55] <jmkasunich> ---
[02:01:55] <jmkasunich> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
[02:01:55] <jmkasunich> 6,8c6,8
[02:01:57] <jmkasunich> < Interrupt: pin A routed to IRQ 11
[02:01:59] <jmkasunich> < Region 0: I/O ports at c000 [size=256]
[02:02:03] <jmkasunich> < Region 1: Memory at dfffbd00 (32-bit, non-prefetchable) [size=256]
[02:02:05] <jmkasunich> ---
[02:02:07] <jmkasunich> > Interrupt: pin A routed to IRQ 193
[02:02:09] <jmkasunich> > Region 0: I/O ports at e800 [size=256]
[02:02:11] <jmkasunich> > Region 1: Memory at ea011000 (32-bit, non-prefetchable) [size=256]
[02:02:13] <jmkasunich> dunno bout dapper until I reboot
[02:02:18] <cradek> Thanks, Paul! Adding "acpi=noirq" works wonderfully.
[02:02:25] <cradek> so I bet that will fix it
[02:03:13] <cradek> they're talking about a motherboard blacklist. maybe yours is bogus (and breezy doesn't use this irq routing)
[02:04:03] <jmkasunich> menu.lst edited... here goes nuttin'
[02:05:55] <cradek> bbl
[02:06:04] <SWPadnos> see you
[02:06:26] <SWPadnos> question for you jepler
[02:06:57] <jepler> ???
[02:06:58] <SWPadnos> can the python emcmodule run without "emc proper" running?
[02:07:27] <SWPadnos> actually, the real question would be - can you use the G-code interpreter outside the context of emc?
[02:07:43] <jepler> yes, the gcode module will work without the rest of emc
[02:07:50] <SWPadnos> I just realized that emcmodule also has status interfaces and the like, which wouldn't work
[02:07:54] <SWPadnos> ok. that's cool
[02:08:06] <jepler> gcode and emc are separate modules
[02:08:44] <SWPadnos> the reason I had asked about cp1 was that I though that it would be interesting to write more of those functions in python, and also use the gcode and 3d modules in axis ffor a preview
[02:09:07] <SWPadnos> which is probably a PITA (especially for me, since I don't know python yet)
[02:09:13] <SWPadnos> but may be useful
[02:09:32] <jepler> yeah originally axis was usable without emc running but that's not true lately
[02:09:45] <jepler> first it was a previewer only, as you may or may not remember
[02:09:55] <SWPadnos> right - too many deep links, like HAL pins and the like
[02:10:04] <SWPadnos> hmmm - I don't know if I knew about it then
[02:11:38] <jepler> by now, yes
[02:12:18] <SWPadnos> in any case, I don't think CAM and machine control should be in the same program, but having preview and testing the G-code produced are both useful
[02:13:37] <SWPadnos> I winder who uploaded a stupid flash pacifier image to the linuxcnc wiki?
[02:21:08] <jmkasunich> no joy
[02:38:03] <jmkasunich> seems the latest ubuntu kernels have more than one regression bug
[02:38:19] <jmkasunich> I'm seeing the messages associated with this one too:
https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/54419
[02:48:38] <cradek> man what rotten luck
[02:51:07] <jmkasunich> gonna try a few variations on the theme
[02:51:13] <jmkasunich> pci=noacpi
[02:51:17] <jmkasunich> acpi=off
[02:51:51] <jmkasunich> I have the kernel logs from both breezy and dapper open side by side
[02:52:04] <jmkasunich> there are interesting differneces, dunno how relevant
[02:52:32] <jmkasunich> how does your nic wind up using IRQ 193 anyway?
[02:53:37] <cradek> using some combination of the four letters a,c,i,p
[02:53:47] <cradek> io-apic?
[16:05:13] <anonimasu> hm
[16:05:19] <anonimasu> does the new to have issues with lots of moves?
[19:25:17] <alex_joni> hi guys
[19:26:04] <SWPadnos> howdy.
[19:26:21] <alex_joni> cradek said he wanted us to talk about 2.1 sometimes
[19:26:24] <SWPadnos> thanks for cp1 alex - it's in the uploads dir now, and I fixed the link on the cp1 page
[19:26:36] <alex_joni> cp1 page?
[19:26:56] <alex_joni> wiki?
[19:27:01] <SWPadnos> there was a wiki page about it, yes
[19:27:07] <SWPadnos> still is ;)
[19:27:29] <alex_joni> ok, found it
[23:54:30] <SWPadnos> cradek, are you around?
[23:54:37] <cradek> yes
[23:55:00] <SWPadnos> were the two checkins you did in response to the problem Paul identified?
[23:55:09] <alex_joni> yes
[23:55:12] <cradek> yes, well one was an accident
[23:55:24] <SWPadnos> ok, I noticed that one undid the other ;)
[23:55:30] <cradek> is the fix wrong? I'm pretty clueless about C++
[23:55:43] <SWPadnos> there's no difference between 1.7 and 1.9
[23:55:54] <SWPadnos> maybe I didn't look at all the files
[23:55:56] <cradek> yeah ignore the Submakefile changes
[23:55:59] <alex_joni> SWPadnos: extern "C"
[23:56:12] <SWPadnos> oh - duh. I didn't see the halmodule part at first ;)
[23:56:20] <cradek> ahh
[23:56:29] <SWPadnos> that makes a lot more sense now ;)
[23:56:35] <alex_joni> cradek: usually I put this in the .h
[23:56:41] <alex_joni> #ifdef __cplusplus
[23:56:42] <alex_joni> extern "C" {
[23:56:42] <alex_joni> #endif
[23:56:46] <SWPadnos> rigth
[23:56:51] <cradek> ah that's smarter
[23:57:02] <cradek> thanks for volunteering to fix it right :-)
[23:57:30] <alex_joni> only on monday
[23:57:31] <SWPadnos> heh
[23:57:41] <alex_joni> unless you want some nice \M in there
[23:57:44] <SWPadnos> I can do that sometime before Monday
[23:57:46] <cradek> ha
[23:58:01] <cradek> so the fix is right, other than being applied wrongly?
[23:58:06] <alex_joni> and n testing ;)
[23:58:10] <alex_joni> no testing
[23:58:15] <alex_joni> cradek: looks about right to me
[23:58:27] <alex_joni> and it's not applied wrongly
[23:58:32] <SWPadnos> I guess the HAL stuff is pretty much all that should needs this, or are there other places where we may have C headers used by cpp code?
[23:58:50] <alex_joni> it's just a source of problems for the future if there's another cpp code that will link it
[23:59:13] <alex_joni> SWPadnos: there are a few places? but I think all are correct
[23:59:17] <SWPadnos> not so much with the #ifdef, I think
[23:59:53] <SWPadnos> hmmm - duh - right. I get what you said now :)