Wayne Knowles <w.knowles@niwa.cri.nz> writes:
> The !PULLUP case is writing data to the scsi controller.  We need to fill
> the FIFO to complete the DMA operation for a SCSI read, but on write it
> has the data already so we can just flush the FIFO when the operation is
> complete.

hmm.

in _setup, in the DMA_PULLUP case you write data to the FIFO, and in
the !DMA_PULLUP case you read it.

in _intr, in the DMA_PULLUP case you again write data to the FIFO,
and in the !DMA_PULLUP case you whack the fifo.

for the DMA_PULLUP case, you're basically filling the FIFO with memory
data which it will then DMA back into memory?

I don't think I understand what the !DMA_PULLUP case in _setup is
doing, then.


(BTW, the comment "XXX - disable DMA xfer before flushing FIFO ?" is
kinda scary -- esp. since you aren't flushing it here, you're filling
it as far as I can tell.  8-)


> My impressions are that the SCSI DMA stuff isn't related to the problem
> since the userland buffer isn't being changed at all.  If it was the DMA
> FIFO it will get over-written with some random data from the fifo.
>
> I have managed to add some debug code to uiomove that picks up on the
> situation - hopefully I can use that do trigger some extra debugging.

right, so, this got back to the question of which operation actually
causes the read to fill the buffer with the bad contents.

If it was read from a raw device, the device is the userland buffer
would be filled directly by device DMA.

If it was a read from a file, well, then that wouldn't apply, and if
your read is going through uiomove then it must be that or a block
device.


I guess I confused myself: As of my e-mail last night, I thought the
problem (a) was being discovered after reading the buffer into dump,
and (b) (based on some quick, non-thorough inspection of the dump
sources) in fact was most likely caused by a read from a raw device.



cgd