Back
[00:05:54] <rayh> This sounds exactly like what would happen occasionally when I was trying to make the computer boards pci device work by sending it inbuf and outbuf commands.
[00:06:03] <rayh> Total machine lockup.
[00:12:44] <skunkworks> reggae fest this weekend - potluck here at noon saturday. every one is invited..
[00:13:37] <skunkworks> sorry about the short notice.. it sort of happened this week. :)
[00:15:27] <skunkworks> (probably mostly a bunch of drunk stoned people around town..)
[00:21:17] <jepler> ha ha "pot" luck
[00:21:57] <jepler> I must be stoned too; I think I just spent an hour reading this pinout before I hooked up my scope probes to the right things
[00:23:14] <jepler> I wonder if there's really a substantial bounce above vcc and below gnd at switching, or if I'm still doing something wrong
[00:34:27] <skunkworks> welcome back
[00:42:58] <skunkworks> jeepers.. irc is a bit odd tonight
[00:43:21] <rayh> I thought it was always a bit odd?
[00:43:32] <skunkworks> heh
[00:43:38] <skunkworks> jepler: bounce?
[00:49:15] <jmkasunich> jepler: do you have a dual channel scope?
[00:49:29] <jmkasunich> if so, trigger using one channel, and probe ground with the other
[00:49:39] <jmkasunich> if you still see the bounce when probing ground, it ain't real
[01:12:38] <jepler> it must be real then
[01:12:54] <jepler> I get identical bounce no matter which probe/channel I use, but when one probe's probing ground there's no bounce
[01:13:33] <jepler> (no bounce on ground, that is)
[01:13:53] <SWPadnos> heh - I was trying to phrase that question :)
[01:17:36] <jepler> * jepler presses the reset button for what feels like the 1000th time
[01:18:10] <skunkworks> heh
[01:18:59] <skunkworks> also - when you get this figured out... (as I know you will) check to see if your relay works.
[01:19:10] <jepler> I did spot something wrong related to the relay
[01:19:22] <skunkworks> neat
[01:20:22] <jepler> http://pastebin.ca/1003522
[01:21:34] <skunkworks> double neat
[01:22:32] <jepler> now, I haven't tested it .. I just noticed it was probably wrong
[01:23:15] <jepler> [ 282.543893] WRITE(c003,0) -> outb(c003)
[01:23:15] <jepler> [ 282.543896] WRITE(c0c0,2) -> outb(c0c8)
[01:23:15] <jepler> [ 282.543898] WRITE(c0c0,1) -> outb(c0c4)
[01:23:15] <jepler> [ 282.543899] WRITE(c0d0,2) -> outb(c0d8)
[01:23:18] <jepler> [ 282.543901] WRITE(c0d0,1) -> outb(c0d4)
[01:23:20] <jepler> [ 282.543903] WRITE(c0e0,2) -> outb(c0e8)
[01:23:23] <jepler> [ 282.543905] WRITE(c0e0,1) -> outb(c0e4)
[01:23:25] <jepler> [ 282.543906] READ(c0c0,0) -> inb(c0c0)
[01:23:28] <jepler> [ 282.543908] READ(c0d0,0) -> inb(c0d0)
[01:23:30] <jepler> [ 282.543910] READ(c0e0,0) -> inb(c0e0)
[01:23:33] <skunkworks> I don't have it here - left it at work. So it ill have to wait. (darn)
[01:23:33] <jepler> I can't imagine what's wrong with this .. but if I actually perform the inb()s of those addresses it sure does die
[01:24:00] <jepler> (and unlike skunkworks experience it doesn't seem to matter whether the input is toggling or not, though the inputs *are* floating)
[01:24:44] <skunkworks> I wondered if that was part of the randomness... the inputs when left unhooked will randomly change state.
[01:35:05] <jepler> this is infuriating
[01:35:11] <jepler> I recommend you just trash the card :-P
[01:35:36] <SWPadnos> is there source code on the driver disc?
[01:35:39] <jepler> troubleshoot it with a shotgun
[01:35:50] <jepler> SWPadnos: there's thai delphi code; who knows if it works as advertised
[01:35:57] <jepler> http://www.etteam.com/download/10PC_INTERFACE/1008/ET_PCI8255_V3_delphi_5.pdf
[01:36:05] <jepler> who knows what is advertised as working :-P
[01:37:42] <SWPadnos> indeed
[01:52:20] <jepler> If I run the thread extremely slowly it doesn't lock the machine, but eventually the writes stop having any effect at the scope
[01:52:34] <jepler> even if I stop and restart hal
[01:53:03] <SWPadnos> looking at their code, they do preserve bits they don't need to modify (in the setup code)
[01:53:35] <jepler> yeah, I saw that too
[01:53:39] <SWPadnos> their port addresses match yours, so that reinforces the assumptions about addressing individual bytes vs. longs
[01:54:04] <jepler> but they're using 32-bit accesses to those byte-aligned registers
[01:54:28] <jepler> which might explain why they try to preserve the other bits -- otherwise when you write register 3 you pork up what's in registers 4 through 6
[01:54:32] <SWPadnos> sort of. I think they just name those functions xxx32
[01:54:42] <jepler> well that didn't occur to me
[01:54:48] <SWPadnos> like 32-bit mode, not 32-bit access
[01:54:53] <jepler> yeah
[01:55:09] <SWPadnos> the source code to the windows driver is available, though I didn't bother to download it
[01:55:24] <jepler> oh and no luck using memory-mapped access
[01:55:30] <SWPadnos> bummer
[01:59:32] <SWPadnos> they do read/write UCHARs (which I'll assume are 8 bits long)
[02:05:50] <jepler> after it goes wrong, the configuration registers all read as 0xff
[02:06:31] <jepler> (this is if I only do a few reads before stopping HAL)
[02:06:47] <SWPadnos> hmmm
[02:07:22] <SWPadnos> well, that could be the cause of the problem or a sign of the problem. either the chip is getting screwed up, or something is causing all those interrupt / DMA modes to get turned on
[02:08:56] <jepler> I wish I didn't believe that inputs worked at one time
[02:11:47] <SWPadnos> are you setting the port(s) to all input, or a mix?
[02:11:52] <jepler> to a mix
[02:12:19] <jepler> I believe that the 82c55 configuration register value I'm writing is 0x90
[02:13:58] <SWPadnos> it's safe to read registers that are configured as output. I wonder if it would be clearer to read all bytes, then process what's needed (at least for debugging)
[02:14:59] <jepler> I find that when I make the READ() function return arbitrary data and not do an inb/inl, it doesn't lock
[02:15:18] <SWPadnos> heh - that's a good thing :)
[02:15:22] <jepler> so I'm pretty sure it's not the organization of all those 'for' loops that are wrong
[02:15:32] <jepler> at least, not wrong enough to cause this problem
[02:15:39] <SWPadnos> sure
[02:16:33] <SWPadnos> can you paste in the most verbose lspci output you can get for the card?
[02:19:02] <jepler> http://pastebin.ca/1003554
[02:19:32] <jmkasunich> jepler: I just though of something that may or may not be usefull
[02:20:00] <jmkasunich> my little PCI lib will let you open the I/O or memory regions of the card and read/write them from a user space program
[02:20:13] <jmkasunich> dunno if that would crash a little more gracefully or not
[02:20:22] <SWPadnos> or use pci_read/pci_write in a shell script
[02:20:32] <SWPadnos> though that may look for Mesa IDs
[02:21:35] <SWPadnos> jepler, when you did the memory-mapped testing, what happened, and what base address did you use?
[02:21:58] <jepler> SWPadnos: the card seemed to do nothing. I used whatever 8-hex-character address was in lspci
[02:22:16] <SWPadnos> ok
[02:23:09] <SWPadnos> I guess a thing to try (like jmk's suggestion) is to make a userspace program that reads/write, using IOPL or similar
[02:23:10] <jepler> well now it fails differently. I never get outputs, and reading back the configuration always gives me wrong values
[02:23:20] <SWPadnos> it may be cold boot time
[02:24:27] <SWPadnos> one thing to do: after a good cold boot (a minute or two off), get a dump of the entire register space
[02:26:18] <jepler> SWPadnos: I did that *before* I said that
[02:26:25] <SWPadnos> oh
[02:26:47] <jepler> the minute off, that is
[02:26:53] <SWPadnos> ok
[02:27:03] <SWPadnos> not the config dump though?
[02:28:47] <jepler> ni
[02:28:48] <jepler> no
[02:28:49] <jepler> I quit
[02:28:58] <SWPadnos> we are the programmers who say "Ni!"
[02:29:42] <SWPadnos> that is an annoying problem - I'm not sure how to go much further without real documentation
[02:34:04] <jmkasunich> you mean docs that aren't written in inscrutable squiggles?
[02:34:51] <SWPadnos> yes
[04:52:27] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[07:42:09] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[14:06:38] <skunkworks_> <jepler> skunkworks: well just send the $65 in the form of one of these PCI cards to: <my postal address>
[14:06:43] <skunkworks_> second thoughts? ;)
[14:17:33] <jepler> at this point I think the board has toasted itself
[14:24:06] <cradek> just send the $130...
[14:26:57] <skunkworks_> Jepler: your pastebin made the relay work.. If that helps :)
[14:27:24] <jepler> well great
[14:28:17] <skunkworks_> * skunkworks_ couldn't remember how to do a patch file - so he just edited the 2 lines..
[14:30:19] <skunkworks_> jepler: you think your card is dead? or are you frustrated?
[14:31:11] <jepler> skunkworks_: I think it may actually be damaged
[14:31:16] <skunkworks_> eww
[14:32:00] <jepler> it has configuration registers that you can set and then read back. when I started last night, that worked properly. Now, some of them are stuck as all-zeros and some of them are stuck as all-ones.
[14:33:04] <cradek> do you think it's one of the (socketed) 8255s?
[14:33:16] <jepler> no, these are the configuration registers of the tiger320 surface-mount chip
[14:33:25] <cradek> heck.
[14:34:03] <cradek> something seems very wrong if you could nuke it using software
[14:34:10] <jepler> I agree
[14:35:39] <skunkworks_> I can send you another one.. I you still want to work on it.
[14:36:01] <cradek> maybe you should try this one in a completely different machine
[14:36:49] <skunkworks_> *If
[14:37:29] <skunkworks_> * skunkworks_ doesn't mind taking one or to for the team.
[14:37:34] <skunkworks_> jeeze
[14:37:36] <skunkworks_> two
[14:39:10] <jepler> I'll let you know
[14:45:48] <skunkworks_> you could also ssh into this machine if you wanted to.. You would just have to tell me when to reboot.. :)
[15:42:47] <skunkworks_> jepler: cool review of your laptop.
[15:52:29] <jepler> thank; I like to find good information about laptop compatability, so the least I can do is provide it too
[15:52:53] <skunkworks_> :)
[15:54:20] <skunkworks_> I did email futurlec and asked again if they have an english version of the programming pdf.
[15:54:27] <skunkworks_> (this morning)
[16:31:13] <skunkworks_> huh.
[17:45:27] <alex_joni> hi
[17:45:55] <rayh> Hi Alex.
[17:51:14] <alex_joni> hey ray
[17:53:05] <rayh> I've got 8.04 running both 32 and 64 bit now.
[17:53:37] <rayh> Thanks for the good work on these.
[17:54:30] <alex_joni> rayh: cool.. I did only half of the work
[17:54:41] <alex_joni> (the other part was jepler )
[17:55:16] <rayh> I'm pretty impressed with the ease of getting them going.
[17:55:36] <rayh> The 64 has a lot larger jitter number than the 32.
[17:55:43] <alex_joni> on the same machine?
[17:55:46] <rayh> I'll play some and see if I can get that down.
[17:55:54] <rayh> No different boxes and all
[17:55:59] <alex_joni> ah.. ok
[17:56:07] <alex_joni> it would be interesting on the same machine
[17:56:36] <rayh> It would. Perhaps I should try your new cdrom on that box and see what shakes out.
[17:58:11] <rayh> I presume I can run latency test from a live boot?
[18:00:06] <cradek> yes
[18:00:35] <alex_joni> rayh: sure
[18:00:55] <alex_joni> (open a terminal, type "latency-test") -> emc's latency test
[18:01:10] <rayh> I'll burn a disk and try it.
[18:01:23] <alex_joni> (open a terminal, type "cd /usr/realtime-*/testsuite/kern/latency && sudo ./run )
[18:01:50] <rayh> the 64 bit install has been running a hacked up cds.ngc for 30 hours now.
[18:04:00] <rayh> It's booting.
[18:04:15] <alex_joni> let me guess.. o-word loop?
[18:04:35] <SWPadnos> veeeeeeeeery low feed rate ;)
[18:04:50] <alex_joni> heh.. or very large BASE_PERIOD :))
[18:05:08] <SWPadnos> one MILLION nanoseconds! muahahahaha
[18:06:26] <rayh> Yuck ugly bird again.
[18:06:38] <SWPadnos> 256-color mode?
[18:09:59] <alex_joni> no.. the background
[18:11:54] <rayh> 19237 worst case
[18:12:32] <rayh> It was a couple hundred k with the 64 bit but I made some changes to bios and will go back and confirm result
[18:13:21] <rayh> glxgears was getting more than 2k frames for each loop.
[18:13:37] <rayh> more than during the 64 bit session.
[18:14:11] <rayh> reboot now to 64 and compare.
[18:17:37] <rayh> 28237106 when I start open office word.
[18:18:02] <alex_joni> 28M ? ouch
[18:18:09] <rayh> So the jitter is much worse in 64 bit
[18:18:36] <rayh> You think I'll run into issues with a 50k pulse rate on steppers???
[18:19:40] <alex_joni> why should you?
[18:19:46] <alex_joni> unless you use full steps
[18:20:37] <rayh> I was getting an occasional note that there was a real time delay.
[18:21:00] <rayh> So ran emc alone when I ran it. Worked okay.
[18:21:13] <rayh> That test though suggests I'm better off with 32 bit.
[18:21:34] <rayh> This is an older asus a8 board
[18:22:54] <alex_joni> interesting
[18:23:51] <rayh> Seems like a strange result.
[18:24:38] <rayh> I suppose that the open office is 65 bit optimized which might make the scheduler stop and think when it starts up.
[18:24:45] <rayh> 64
[18:25:43] <alex_joni> yeah, but RT should be affected by the scheduler
[18:35:03] <rayh> 4175324 this time using default bios.
[18:35:24] <alex_joni> that still means overrides
[18:35:47] <rayh> It looks to me like, with this board and proc I'm better off with the 32 bit install.
[18:47:15] <BigJohnT> alex_joni: you around?
[18:47:49] <alex_joni> yup
[18:48:39] <BigJohnT> I ran my plasma cutter on 2.3 last night with the machine torch
[18:48:51] <alex_joni> pre-2.3
[18:48:58] <BigJohnT> the home final velocity is sweet
[18:49:03] <BigJohnT> yes pre-2.3
[18:49:08] <BigJohnT> cvs
[18:49:59] <BigJohnT> do you know if the o word call will open a file in pre 2.3 yet?
[18:50:10] <alex_joni> it should in 2.2 too
[18:50:21] <alex_joni> but it will not run that file
[18:50:38] <BigJohnT> hmmmm
[18:50:41] <alex_joni> it will open the file and run a procedure with the same name as the file
[18:51:01] <BigJohnT> is the syntax different?
[18:51:10] <alex_joni> no.. you just call a procedure
[18:51:25] <alex_joni> if that isn't found in the current program, it tries to open a file with the same name
[18:51:36] <alex_joni> and looks in that file for a procedure by that specified name
[18:52:13] <BigJohnT> would the file name be o100.ngc or just 100.ngc?
[18:52:50] <alex_joni> BigJohnT: gotta admit, that beats me :D
[18:53:06] <BigJohnT> yea, I could not figure it out last night either
[18:53:47] <BigJohnT> did some grepping and could not find any info on it in the files...
[18:54:09] <BigJohnT> anyhow tests ran rather well. video soon I hope
[18:55:04] <alex_joni> I think o100.ngc
[18:55:28] <BigJohnT> ok, thanks I'll try again tonight
[22:06:02] <BigJohnT> ok
[22:06:19] <alex_joni> CIA has a message for you
[22:06:27] <BigJohnT> ok
[22:06:42] <alex_joni> seems a bit slow
[22:06:43] <CIA-31> EMC: 03alex_joni 07TRUNK * 10emc2/docs/src/gcode/main.lyx: include documentation fix from BigJohnT - describes usage of including ngc files using O-words
[22:06:56] <BigJohnT> Sweet!
[22:07:20] <BigJohnT> you know you opened up a can of worms now...
[22:07:37] <alex_joni> well.. if you want to work on docs..
[22:07:44] <BigJohnT> yep
[22:07:54] <alex_joni> (take this as encouraging a new contributor)
[22:08:15] <BigJohnT> I have the mpg pendent on the way for testing
[22:08:20] <alex_joni> cool
[22:08:58] <BigJohnT> ok do I need to d/l trunk often to keep up?
[22:12:19] <alex_joni> BigJohnT: well.. it changes from time to time
[22:12:32] <BigJohnT> once a week or so?
[22:13:32] <BigJohnT> holy crap it's tomorrow at your house!
[22:14:46] <BigJohnT> * BigJohnT waddles out to the fab shop to work on plasma cutter
[22:14:53] <BigJohnT> good night alex
[22:15:24] <alex_joni> good night
[22:15:29] <alex_joni> (it's 1am here ;)