[186] in linux-scsi channel archive
SCSI Reset Functions
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Sat May 20 20:49:36 1995
Date: Sat, 20 May 1995 16:55:45 -0700
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
To: linux-scsi@vger.rutgers.edu
Cc: eric@aib.com
Cc: Drew Eckhardt <drew@boulder.openware.com>
I have a dilemma regarding how to implement the device-specific reset function
for the new BusLogic driver I'm working on. There seem to be several options,
but doing what seems like the right thing seems to have some undesirable side
effects.
Consider the case where a find command such as
find /cd -noleaf -type f -exec md5sum {} \;
over a mounted CD-ROM receives a read error which causes the higher levels to
eventually call the device-specific reset function after the command has been
retried a few times (e.g. a flakey CD-ROM drive, or a bad spot on the CD-ROM,
such as would be caused by a Sharpie marker for testing). In order of
increasing severity, I see four options for what the device-specific reset
function can do:
1. Do nothing and return SCSI_RESET_PUNT
2. Send the device a BUS_DEVICE_RESET and return SCSI_RESET_SUCCESS
3. Reset the SCSI Bus and return SCSI_RESET_PENDING
4. Reset the Host Adapter and SCSI Bus and return SCSI_RESET_SUCCESS
In case (1), an individual call to md5sum will fail but the find will proceed
and subsequent calls to md5sum will probably succeed. Unfortunately, no reset
has really been done so what was the point of calling it in the first place?
If the SCSI Bus really were wedged in some way, we haven't done anything to
address that.
But in any of cases (2), (3), or (4), the CD-ROM device really is reset and
will return UNIT_ATTENTION and then NOT_READY to any further commands, so all
of the remaining md5sum commands will fail with an I/O error.
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
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.
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.
Without such changes, my present inclination is to conditionalize the reset
function on the type of the device that's had a failure. If a disk has enough
problems to get to the reset stage, ideally I'd want to try option (2) first
and then proceed to option (4) if necessary.
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).
Is there any right answer to what I should do?
Leonard
