|> With May 22 sources the ordinary st driver was disabled and we were
|> building st from the main tree, with less than satisfactory results - what
|> was supposed to be mt status went out as something else, like a fsf or
|> something (thank heavens not a weof!)  Kids don't try this at home.
| 
|   Nothing should have changed as far as the IOCTL calls from mt, since both
| the old Amiga st driver and the new scsi one used the same definitions
| (in sys/mtio.h).  However, the interpretation of the minor number has changed.
| 
|   The Amiga driver expects the tape device to be defined as follows:
| 	/dev/rst0	minor number = 0
| 	/dev/nrst0	minor number = 4
| 
|   The new st driver expects the following:
| 	/dev/rst0	minor number = 0
| 	/dev/nrst0	minor number = 1
| If the existing /dev/nrst0 (minor number = 4) is used, the 4 is one of the
| density bits, so it will still rewind the tape device.

All I'm going on is that the drive seemed to be doing tape motion, and
I guess that could account for it, although since it was already at BOT
I wouldn't have thought it would take so long.  If the src/sys/scsi/st.c
is what we're going to be using, I'll have a look at it if I get time.

I have been meaning to look at st anyway, because it locks the system while
doing tape motion, which probably isn't the desired effect.  For example,
type "mt -f /dev/nrst0 fsf 1".  The SCSI LED goes on and stays on, the
keyboard is 99% disabled, mouse disabled, etc.  (I can get a few characters
through to the keyboard, to show on the screen after the tape's through,
but most of them are just dropped.)  The drive is an Exabyte 8200; no
problem with BTNtape.

	Donn Cave, donn@cac.washington.edu

------------------------------------------------------------------------------