[5137] in linux-scsi channel archive
Re: Scsi tape - returns ENXIO after an error (aha1542 + others)[PATCH]
daemon@ATHENA.MIT.EDU (Richard Fish)
Sat Nov 14 19:56:10 1998
Date: Sat, 14 Nov 1998 12:39:45 -0700
From: Richard Fish <rjf@estinc.com>
To: linux-scsi@vger.rutgers.edu
Kai M{kisara wrote:
>
> This is sent to linux-kernel only because it replies a message sent there.
> We really should keep this discussion in linux-scsi!
I couldn't agree more. This is something that should be handled within
linux-scsi. However, my posting of an aha1542 patch to fix this problem
3 weeks ago to linux-scsi didn't generate any response at all. I had
several after I reposted to linux-kernel... Those responses led me to
replace that patch with this one.
> On Fri, 13 Nov 1998, Richard Fish wrote:
>
> > C S Hendrix wrote:
> >
> > In message <3649ADCF.87BC328A@estinc.com>, Richard Fish writes:
> ...
> > [snip]
> >
> > > Is there a way to do this in a way that is not specific to the SCSI
> > > controller driver? Or would each low-level driver have to receive
> > > a similar patch?
> >
> > Ok, here is a patch to scsi_error.c that will hopefully fix the problem
> > for all controllers. This removes the need for a patch to aha1542.c.
> > Please test and let me know if there are any problems.
> >
> >--- scsi_error.c.old Mon Jul 27 18:21:59 1998
> >+++ scsi_error.c Fri Nov 13 08:42:21 1998
> >@@ -945,6 +945,18 @@
> > }
> >
> > /*
> >+ * For tape drives, pass common failures to high-level driver
> >+ */
> >+ if( SCpnt->device->type == TYPE_TAPE &&
> >+ (status_byte(SCpnt->result) == GOOD) ||
> >+ (status_byte(SCpnt->result) & CHECK_CONDITION))
> >+ {
> >+ SCpnt->result &= 0xff00ffff;
> >+ return SUCCESS;
> >+ }
>
> Your patch practically bypasses the error handling for tapes and this is
> not correct. It would be better to selectively fix the error responses
> that cause problems.
With tape drives, the error handling appears to BE the problem. First,
it can't "fix" the original problem, so the end result is that the drive
is taken offline. The lowlevel scsi module must then be reloaded in
order for the drive to be usable again. And if you happen to use the
non-rewinding device to put multiple archives on a tape, you will never
be able to access anything but the first archive. This is VERY bad!
> I don't have any SCSI adapter that uses the new error handling and so the
You're very lucky then...
> following is just speculation. The function scsi_check_sense() returns
> SUCCESS in case of UNIT_ATTENTION and the comment says that in this case
> the the information is passed up to the upper level driver. This is what
> want to happen with FM, EOM, and ILI. If the test near the beginning of
> the function is changed to
>
> if (SCpnt->sense_buffer[2] & 0xe0)
> return FAILED;
>
> it might help.
Ok, I think I understand what you are suggesting here -- but shouldn't
the return value be SUCCESS? If the FM,EOM, or ILI bits are set, we
don't want the error handler to run, so we would need to return
SUCCESS. I must admit, I am new to SCSI programming, and I left my SCSI
documentation at work, so I am speculating as well...
> Before even thinking to add something like this to the kernel, someone
> should check what the result would be for the whole middle-level SCSI
> system, taking into account all device types.
Well, my patch above should only affect tape drives, right? So far,
I've only received one report from someone applying this patch, and it
was positive. I received 3 on the aha1542 specific patch, all positive.
Kai, I'm certain that you are much more experienced in this stuff than I
am, so if you say this is wrong, then I won't argue. But the current
error-handling mechanism causes major problems for many people using
tape drives, and really MUST be fixed before 2.2 can become a reality.
Any and all suggestions are welcome!
--
Richard Fish Enhanced Software Technologies, Inc.
Software Developer 4014 E Broadway Rd Suite 405
rjf@estinc.com Phoenix, AZ 85040
(602) 470-1115 http://www.estinc.com
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
