[187] in linux-scsi channel archive
SCSI Reset Functions
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Sun May 21 14:16:42 1995
Date: Sun, 21 May 95 13:45 EDT
From: eric@aib.com (Eric Youngdale)
To: linux-scsi@vger.rutgers.edu
Cc: "Leonard N. Zubkoff" <lnz@dandelion.com>
Cc: Drew Eckhardt <drew@boulder.openware.com>
>My inclination is to think that the device-specific reset function should be
>called as the last gasp at recovery when things are really broken, and so it
This is already the case. Basically this should only happen when
commands fail or time out.
>would want to be as conservative as possible in resetting the state so that the
>system can continue operation. Thus my initial implementation was option (4).
>The system seems to recover disk access just fine, but my testing pointed up
>the problems with a mounted CD-ROM.
Option 1 is really not a good option. It does not help anything.
It is only there so that if you have no good way of resetting the bus,
or you do not want to reset the bus for some reason, you have something
to report to the mid level code. Some cdrom drives will keep retrying,
and may eventually succeed, so this is not as far fetched as it seems.
Option 2 is more attractive. It basically resets a single device,
which leaves the other devices on the bus alone. There are circumstances
where this does not help, however, but I tend to view this as the
most conservative option.
Options 3 and 4 are used when you actually perform a bus reset.
You use 3 if the reset is still in progress when you return, and 4 if
you know that the reset has completed. It is up to you which one you
use.
>It seems to me that if we are going to reset the SCSI bus without requiring
>unnecessary user intervention, the mid/high level parts of the SCSI subsystem
>need to be able to restore the state of active devices where this makes sense.
>With devices such as a DDS DAT drive, it may well be impossible to restore the
>state properly after a bus reset.
I know. This is why I have not implemented a bus reset for
the 1542 driver, for example. I think with a DAT drive, we need to
set a bit saying that the position is lost, and we return an error
code until the user tells the tape to rewind, or a new tape is
inserted. I have asked Kai Makisara about this, and he said the idea
seemed reasonable.
Most other devices should not be that bothered by a bus reset,
except for removable disks where the door lock will be released.
FWIW, this is the next thing I was planning to add better support
for after the 1.3 series gets started.
One thing that will be in the 1.3 series is a /proc/scsi directory
with a separate file for each low level driver. Some of us were toying with
the idea of allowing the system administrator to perform a bus reset simply
by writing a special string to this "file". My concern is that a bus
reset is a pretty severe thing to do, and it is something to be avoided if
at all possible, and if any other course of action is available.
>Discussion and suggestions? From the other drivers I've examined, it seems
>they all choose a specific strategy for every device, but the choice seems to
>be predicated more on what the adapter card is capable of than the possible
>effects on the target device(s).
From the low-level driver point of view, this is probably the right
thing to do. You have certain capabilities and have to make do with
what you can do.
I would also be interested in hearing other comments.
-Eric
