🚀 go-pugleaf

pc532@bungi.com writes:
 > 
 > In article <m0mO0oC-000098C@daver.bungi.com>, dlr@DAVER.BUNGI.COM (Dave Rand) writes:
 > > 1) SCSI devices will always transfer in block unit sizes (usually 512 bytes)
 > > before requiring service via an interrupt. Even during disconnect/reconnect,
 > > it *seems* that this is the case, but is not required by the standard.
 > ...
 > They have lots of experience with LOTS of SCSI devices.  Let me assure
 > you that anything that is allowed by the standard, by intent or by
 > loophole, happens.
 > ...
 > Disks are often well-behaved in regard to when they disconnect, but not
 > always.  Cacheing disks, in particular, may disconnect at any arbitrary
 > point in a transfer because its internal scheduler has detected that
 > a desired sector for reading or writing has come up, and the disk needs
 > to service its internal cache.  Fun, right? Really, REALLY high-performance
 > ...
 > Also, tape devices get weird.  For one thing, you could be reading
 > any arbitrary block size from a 9-track tape, particularly foreign
 > host tapes (not that a lot of you are going to use 9-track...) BUT
 > there are DAT and 8mm devices which have ODD SIZED write buffers,
 > like 250 (NOT 256) bytes.  They suck up that much data, disconnect,
 > get the tape moving, then reconnect and suck in more data.  Really
 > sweet, right?

This is bad news. The driver I am working on has a bit mask which says
whether a target is allowed to disconnect. I guess my first approach will
be to assume that targets are "well behaved" and disable disconnection
on any that aren't.

It looks like adding the hardware counter is the only real solution,
although I think I will forget about it until I meet a target that
doesn't work with the "integral number of blocks" assumption.

Thanks for the info.

Ian