On one of my NetBSD/sun3 machines, I have a tape drive:

si0 at vmes0 addr 0xff200000 level 2 vector 0x40 : options=3
scsibus0 at si0
...
st2 at scsibus0 targ 6 lun 0: <TANDBERG, TDC 3800, =03:> SCSI2 1/sequential removable
st2: rogue, drive empty

This drive used to be on a NeXT running release 2.1.  There, I used it
to write a tape, using my tar, which writes blocks of 10K bytes.

Now, with the drive on the NetBSD/sun3 system, I try to read that tape,
and I get EIO from the I/O attempt (dd, tar, whatever) and on the
console I see

st2: block wrong size, 1 blocks residual

where the 1 is replaced by the actual number of blocks in the I/O that
the program attempted - or at least, it was 20 when I used dd bs=10240,
and it was 112 when I let my tar do its auto-blocksize-detect thing,
which tried to do a 1048577-byte read(), which si_minphys trimmed back
to 0xe000=57344 bytes, which sure enough is 112 512-byte blocks.

It's not just that the tape drive is broken; another tape, written
under NetBSD, is readable just fine.

Interestingly, if it's the first I/O since changing the tape, I can
hear the transport whirring for quite a while before I get the error.
(Actually, this always happens, but if it's the first attempt since
changing the tape, it whirs back and forth for much longer.)  Is this
sort of thing what ST_Q_SENSE_HELP is for?  Would it be worth trying
dropping in a quirk entry for this drive?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B