From: "Jeff V. Merkey" <jmerkey@vger.timpanogas.org>
To: Kai Makisara <Kai.Makisara@kolumbus.fi>
Cc: linux-kernel@vger.kernel.org, jmerkey@timpanogas.org
Subject: Re: SCSI tape load problem with Exabyte Drive
Date: Wed, 17 Oct 2001 10:55:35 -0700 [thread overview]
Message-ID: <20011017105535.C24698@vger.timpanogas.org> (raw)
In-Reply-To: <20011016153623.A21324@vger.timpanogas.org> <Pine.LNX.4.33.0110170935300.2271-100000@kai.makisara.local>
In-Reply-To: <Pine.LNX.4.33.0110170935300.2271-100000@kai.makisara.local>; from Kai.Makisara@kolumbus.fi on Wed, Oct 17, 2001 at 09:43:42AM +0300
On Wed, Oct 17, 2001 at 09:43:42AM +0300, Kai Makisara wrote:
> On Tue, 16 Oct 2001, Jeff V. Merkey wrote:
>
> >
> >
> > On 2.4.6 with st and AICXXXX driver, issuance of an MTLOAD command
> > via st ioctl() calls results in a unit attention and failure of
> > the drive while loading a tape from an EXB-480 robotics tape
> > library.
> >
> > Code which generates this error is attached. The error will not
> > clear unless the code first closes the open handle to the device,
> > then reopens the handle and retries the load command. The failure
> > scenario is always the same. The first MTLOAD command triggers
> > the tape drive to load the tape, then all subsequent commands
> > fail until the handle is closed and the device is reopened and
> > a second MTLOAD command gets issued, then the drive starts
> > working.
> >
> This is a "feature" of the st driver: if you get UNIT ATTENTION anywhere
> else than within open(), it is considered an error. In most cases this is
> true but MTLOAD is an exception. I have not thought about this exception
> and noone before you has reported it ;-)
>
> As you say, the workaround is to close and reopen the device after MTLOAD.
> You should not need the second MTLOAD.
>
> I will think about a fix to this problem. The basic reason for not
> allowing UNIT ATTENTION anywhere is that flushing the driver state
> properly in any condition is complicated and there has been no legitimate
> reason to allow this. However, here it should be sufficient to use a no-op
> SCSI command after LOAD to get the UNIT ATTENTION.
>
> Kai
>
Kai,
Thanks for the prompt response. We will continue using the current
recovery method since this appears to work based upon your
description of what is happening here. I will remove the second MTLOAD
command and test with the robotics library. Sounds like it should
work OK. Please let us know what you decide if you feel a workaround
is needed for this problem, and we will be happy to test it for
you.
Do-na-da Go-hv-e
Wa-do
Thanks
Jeff
next prev parent reply other threads:[~2001-10-17 16:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-16 22:36 Jeff V. Merkey
2001-10-17 6:43 ` Kai Makisara
2001-10-17 17:55 ` Jeff V. Merkey [this message]
2001-10-18 1:20 ` Jeff V. Merkey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011017105535.C24698@vger.timpanogas.org \
--to=jmerkey@vger.timpanogas.org \
--cc=Kai.Makisara@kolumbus.fi \
--cc=jmerkey@timpanogas.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®