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.

| > I had a quick look at st.c but I'm not sure why it (stopen presumably)
| > returns ENXIO.  Is there something I should add to the quirks list?
| 
| Jason Thorpe wrote :
| > ENXIO is "device not configured".  EIO is input/output error.  Try looking
| > for EIO.
| 
| Thanks.  Teach me to look at code before tea break!  In that case, it looks
| like the Exabyte returns an error from scsi_test_unit_ready(), even with
| SCSI_IGNORE_MEDIA_CHANGE set.  Does anyone else see this?  Is it worth
| bothering with (admittedly it is only a minor annoyance)?