Subject: Re: Exabytes and gdb
To: J.D.Coleman <J.D.Coleman@newcastle.ac.uk>
From: Ken Wellsch <firstname.lastname@example.org>
Date: 07/08/1997 09:18:14
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)?