Apparently, some early 4/100 DMA controllers do illegal memory access on
large ( >= NBPG ) transfers at the end of the transfer. This appears
as SI_CSR_DMA_BUS_ERR in the csr. To work around this, we simply
transfer the (up to 3) missing bytes from the bpr. We were doing this
anyway, so the work-around is to ignore the bus error.
BUT! I goofed when I implemented the "left-over byte" code for the sw!
It *should* be correct now. Keep metrics (acceeible via DDB) on the number
of 1, 2, and 3 byte clean-ups, as well as the number of "clean" transfers,
just so we can get a clearer picture.
Thanks to Andrew Gillham <gillham@whirlpool.com> for noticing this!
only get these during autoconfiguration and during crash dumps. During
autoconfiguration, the transfers are small enough that DVMA won't be used
anyway. However, using DVMA during a crash dump can be dangerous,
depending on the nature of the panic, so we avoid it.
Correct the DMA transfer count when the target disconnects before
the whole transfer is completed. (Affects VME writes)
Reselect now works on the VME si board!
obio framebuffer. Noticed when my 4/260 dropped into DDB and the screen
didn't unblank. Pull all of the video enable/disable into functions so
this mishap doesn't happen again.
rather than SEEKCOMPLETE before retrying the operation. If implied seeks
are being used, the state is set to DOIO (no change). This is why I
couldn't reproduce the disk_unbusy() panic on my SS2; it uses implied
seeks. Patch from John F. Woods <jfw@jfwhome.funhouse.com>
[prevents disk_unbusy panic when disk is loaded (if no
free IOPBs, xdstrategy() would queue the buffer for pickup
by xdcintr() but xdcintr() would never call disk_busy().
xdc_startbuf() is a better place since all bufs are routed
through here] problem detected by girish@dworkin.wustl.edu,
diagnosed and corrected by me.
- move disk_unbusy() call in xdc_remove_iorq() before the call to
XDC_FREE() [don't want to access a data structure that was just put
on a free list]
