lkml.org 
[lkml]   [1998]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Scsi tape - returns ENXIO after an error
On Fri, 9 Oct 1998, Steven N. Hirsch wrote:

>
>
> On Fri, 9 Oct 1998, Harald Koenig wrote:
>
> > On Oct 09, Itai Nahshon wrote:
> >
> > > Hello,
> > > I got a new DDS2 tape drive (Sony SDT-7000). I'm trying to read
> > > an old tape (probably not compatible) and I'm getting this error:
> > >
> > > nahshon# tar vtf /dev/st0
> > > tar: Read error on /dev/st0: I/O error
> > > tar: At beginning of tape, quitting now
> > >
> > > Later, I cannot use the tape drive:
> > >
> > > nahshon# tar vtf /dev/st0
> > > tar: Cannot open /dev/st0: No such device or address
> > >
> > > The only way to recover is to unload and reload the st module
> > > (if I use a modularized kernel).
>
> > this is the same which happens to me too using 2.1.119 to 122
> > with SCSI tapes (DDS1 and QIC150) connected to an AHA1542,
> > but I don't see it for DDS2 connected to NCR810.
>
> Am I imagining things, or isn't this a long-standing problem noted on
> Alan's "to-do" list? I don't know if Kai Makisara reads this list, so has
> anyone E-Mailed him directly with a report?
>
I do read this list, although this is not the correct list for this
problem (SCSI problems should be discussed on linux-scsi). I don't know
what Alan means.

I have done some investigations on the problem:

- ENXIO is returned from some location in st.c, but I suspect that it
comes from this:

if( !scsi_block_when_processing_errors(scsi_tapes[dev].device) ) {
return -ENXIO;
}

Could someone of you confirm this with a printk? If this is not the case,
please forget that I wrote anything below this.

The same piece of code is used also in the other high-level SCSI drivers.

- scsi_block_when_processing_error(SDpnt) (in scsi_error.c) is essentially
'return SDpnt->online'. This flag is set when a SCSI device is detected
and found to respond. The flag is not set anywhere else but it is reset in
some locations in scsi_error.c (seems to be related situations where a
device does not respond "correctly" after a bus or device reset). This
explains that, if the reset fails, the device is gone until the driver is
reloaded.

If the theory above is correct, it explains why the device "disappears"
after SCSI reset is performed by the middle-level driver. This leaves the
question why the reset is being attempted. The timeouts the tape driver
uses by default are very long. However, there are other timeouts in the SCSI
protocol (on the signal level) and it may be that in some cases certain
drives don't respond fast enough. One common reason for SCSI timeouts are
the cables and/or termination. This may explain some resets but in most
cases I have heard about the cables and termination seem to be OK.

Kai



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.091 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site