Ken Wellsch wrote:
> I see precisely this behavior on a NetBSD/i386 system (Pentium Pro)
> with nearly -current (Jun 28 tar_file's) and an Exabyte 8700 series drive
> (oh yeah, using an Adaptec 2940 controller).
> 
> ahc0: target 5 synchronous at 5.0MHz, offset = 0xb
> st0 at scsibus0 targ 5 lun 0: <EXABYTE, EXB-8505, 0051> SCSI2 1/sequential removable
> st0: drive empty
> 
> i.e. an "mt status" produces I/O error.  It does this when the drive has
> the tape ejected and is open, and just loaded until it has gone through
> all the wiz's and chug's then after a minute or two it will be okay. I've
> also found that on some occasions, if left long enough (ten's of minutes
> or hours? not sure) it *may* not do the I/O error but give a clean status. 
> I've also seen that if I don't remember to do an "mt status" to "clear"
> this potential problem it might impact my automated dump in the early AM.

If I try to access the drive when there is no tape, I get an I/O error
and also :

	st0(esp0:4:0): not ready, data = 00 02 00 00 00 23 00 00 00 00 c9 00 00 00 00 00 00 00 02 00 00

on the console.  This seems fair enough to me.  When I try with the tape in,
I always wait until the tape has loaded (tape stops whirring, light stops
flashing) and it consistently hiccups first time.  I've not tried leaving it
more than a few minutes.  As for dumps, I do an 'mt stat' at the start of my
dump script and just ignore the error.

I'll try leaving the drive alone for a while after loading a tape and see if
that makes any difference - that would point to a problem with Exabytes.
Does anyone see this with different types of tape?

J