Date: Thu, 2 Dec 1999 22:17:05 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Stephen McKay <syssgm@detir.qld.gov.au> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Tape driver problems Message-ID: <Pine.BSF.4.10.9912022155061.23244-100000@beppo.feral.com> In-Reply-To: <199912030244.MAA04138@nymph.detir.qld.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thursday, 2nd December 1999, Matthew Jacob wrote:
>
> >> "mt status" with no tape loaded gives an error:
> >>
> >> mt: /dev/nrsa0: Device not configured
> >>
> >> which seems a bit harsh. Also the kernel logs error messages like:
> >
> >Yes, let me think about the error a bit. It may be more a question of
> >changing 'mt' to report something other than just perror.
>
> I think 'Device not configured' should be reserved for when the device
> is truly non-existent, not just when it has no tape.
Sigh. This is a tough one. Solaris (the 'gold' standard here :-)) says:
EACCES The driver is opened for write access and the tape
is write-protected or the tape unit is reserved by
another host.
EBUSY The tape drive is in use by another process. Only
one process can use the tape drive at a time. The
driver will allow a grace period for the other
process to finish before reporting this error.
EINVAL The number of bytes read or written is not a mul-
tiple of the physical record size (fixed-length
tape devices only).
EIO During opening, the tape device is not ready
because either no tape is in the drive, or the
drive is not on-line. Once open, this error is
returned if the requested I/O transfer could not
be completed.
ENOTTY This indicates that the tape device does not sup-
port the requested ioctl function.
ENXIO During opening, the tape device does not exist.
ENOMEM This indicates that the record size on the tape
drive is more than the requested size during read
operation.
The sa(4) man page doesn't say what these values should be for FreeBSD.
Currently saopen returns:
ENXIO - if it couldn't get the periph structure (no such
device).
if it couldn't acquire the periph structure.
if the device has been marked invalid
(AC_LOST_DEVICE)
EBUSY - if the drive is already open.
error - if it couldn't lock the periph structure lock,
which itself calls cam_periph_acquire which will
return ENXIO if the periph pointer is NULL.
whatever samount returns, which will pretty much
be whatever the generic midlayer code decides is
appropriate based upon Sense Key/ASC/ASCQ for each
command that is used during the mount operation.
I suspect that this is where the ENXIO is coming
from.
If the last statement above is true, what you're asking for samount to be
beefed up so the reason that samount fails can be propagated back to
saopen which can then propagate back something more sensible to the caller
(mt(1) in this case). Still, when all is said and done, mt(1), or other
'aware' applications, would have to be then beefed up to understand what a
particular errno on open 'means'.
Well, send-pr it as an RFE. It'll be a post 4.0 thingie tho.
>
> >I'll have to check what happened here. Do you have CAMDEBUG defined?
>
> Hmm. That looks like the sort of thing I might do. ;-) I'll confirm
> tonight to see if this is my fault.
>
> >Hmm, indeed. The density determining code does indeed issue a read of
> >MAXPHYS bytes. It seems to me that all HBA's should at least support that!
> >The maintainer for the 1542X will have to speak to this tho...
>
> I'll help with fixing the 1542B devices. I have lots of them!
I may solve this a different way. It may be just too much breakage to try
and read MAXPHYS, particularly when either the HBA driver is broken. I
actually have a 1542CF, but I'm not going to spend time now debugging that
HBA driver.
Try and change the MAXPHYS sizes in samount to 8192. I've done this to see
what happens (not really sure yet whether it works as well as I'd like). I
think that even an overrun record is fine for the throaway read I'm doing
in samount- all this is trying to accomplish is to get the tape drive to
*attempt* a media access- the contents of the data or the success/failure
is irrelevant. The attempt at media access should get the f/w in the tape
drive to figure out what kind of media is inserted, even if the read fails
to transfer any data at all (like, even if there's a BLANK CHECK the
drive will know what kind of media is inserted (hopefully)). Let me know
if that works better- as soon as possible would be good.
-matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9912022155061.23244-100000>