> OK. I understand what you are saying now. When the IRQ 2 interrupt
> happens, it means that I have to manually go out and check interrupts
> 8-15 rather than having it just happen.
> : beq a0,2,poll_second # cascade?
> : li s1,1 # delay slot
> : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Insert these two lines
> Hmmm, similar lines in rpc44.S do indeed solve the problem. My
> Buslogic card seems to be properly initialized. Or at least the
> interrupts for it are happening now. It is having some problems on a
> bare naked scsi bus (well, one that has one device off attached
> externally), but I'm checking now with a populated scsi bus.
> Hmmm. I have a target 3 drive on the bus, properly terminated, and am
> seeing that it is aboriting commands and resetting the bus. I get a
> lot of bus reset for host 0 messages. In fact, all the commands seem
> to be coming back with all 0's. Hmmm, well, at least it is progress
I had those aborts with the DPT, too. This could either mean that the
driver still doesn't get interrupts or you have problems with the
caches. The DPT eg writes status information about a command into the
memory. You now read something from this data which also (KSEG0!)
is written into the cache while to command isn't complete yet. Later on
this (or another) command is complete, you attempt to read the stale
from the memory but instead get the data from the cache - the
controller waits longer for the data ... Sometimes this effect is
quite invisible; eg. the DPT needed 25 minutes for a certain disk
benchmark. After adding the cacheflush only 13:24 left with the data
flowing continuously, not in bursts.
PS: Rule of thumb for MIPS programmers: If it doesn't work blame the