Folks...I just checked in a change to the sw driver, and I'd like some 
feedback from 4/100 users ...

Here's the commit message:

----- snip -----

Attempt to work around a hardware bug that screws up DMA on the 4/100. 
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!

----- snip -----

Anyone using a 4/100: can you please turn on DMA (use the flags directive 
when you compile the kernel ... see si.c for details) and let me know if 
this fixes the "dma error" problems?  Well, it should fix the error 
reporting, due to the nature of the kludge ... but I'd like to know if 
this fixes e occasional data corruption that some people have obverved 
when using DMA on the 4/100.

Note that metrics are kept on the work-around.  From time to time, if you 
could drop into DDB and e-mail the result of:

db> x sw_3_leftover
    <output>
db> x sw_2_leftover
    <output>
db> x sw_1_leftover
    <output>
db> x sw_0_leftover
    <output>

Thanks!

--------------------------------------------------------------------------
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939