> On Fri, 9 Oct 1998, Steven N. Hirsch wrote:
> > > 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.
Absolutely. I for one *NEVER* read linux-kernel except if I get
really bored. I do read linux-scsi.
> 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.
Your analysis is completely correct. Note however that only
low-level drivers that use the new error handling code will ever set a
device offline, but the 1542 is one of the few drivers that is using this
now.
> 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.
The basic goal of this piece of code is to avoid an infinite
string of resets in the event that some device goes completely insane, or
the bus is so noisy that it becomes impossible to reliably transfer data.
It has been on my todo list to add a means (probably via /proc) to
re-enable a device that has been set offline, but I haven't gotten around
to it.
-Eric
-
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/