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