> On Fri, Apr 17, 1998 at 09:12:18PM -0600, Michael L. Hitch wrote:
> >   The block limits seem rather strange - I'd suspect they are probably
> > garbage.  The buffer for the block limits doesn't appear to be cleared

  Not so strange:  16777215 is 0xffffff - the maximum unsigned value for
the 3 byte field for the maximum blocksize;  33925 is 0x8485 - the "filler"
I stuffed into an aligned buffer when trying to deal with an unaligned
transfer.

> So it is not possible to correctly transfer odd-sized blocks to unaligned
> buffers doing multi-segment magic... you have to poll them, or bounce buffer
> the WHOLE transfer.

  Programmed I/O transfers present a nasty problem:  the transfer has to be
done with asynchronous transfer, and if synchronous transfers have been
negotiated, the driver has to re-negotiate for async transfers.  The
MI ncr53c9x driver doesn't have any clean way to do this.

  The FastLane driver uses an aligned "bounce" buffer in this case, but
I haven't been able to get the partial longword of data at the end of
the transfer into memory when the partial transfer is 1 or 2 bytes.  (When
the partial transfer is 3 bytes, it will get written to memory.)  The old
FastLane driver didn't have this problem, but I could never figure out
what it was doing that the the new driver doesn't do.

Michael
---
Michael L. Hitch                        mhitch@montana.edu
Computer Consultant,  Information Technology Center
Montana State University, Bozeman, MT     USA