[188] in linux-scsi channel archive
SCSI Reset Functions
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Sun May 21 15:06:39 1995
Date: Sun, 21 May 1995 11:39:04 -0700
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
To: eric@aib.com
Cc: linux-scsi@vger.rutgers.edu, drew@boulder.openware.com
In-Reply-To: Eric Youngdale's message of Sun, 21 May 95 13:45 EDT <m0sDF43-0009WLC@aib.com>
Date: Sun, 21 May 95 13:45 EDT
From: eric@aib.com (Eric Youngdale)
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.
Agreed. Despite all the code I see in buslogic_reset in the current BusLogic
driver, that's all it really does -- nothing! I am a bit concerned that if I
implement a proper bus or driver reset before the higher levels are able to
recover, there is at least one person with a flakey CD-ROM drive that will have
problems. However, there's nothing to stop them from commenting out that reset
code on their system.
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.
I recently had a case where using an Adaptec 1542 along with my PCI BusLogic
cards could hang the SCSI subsystem (combined PCI/VL Pentium motherboards seem
to have problems when both PCI and VLB/ISA devices use bus-mastering). I
believe resetting the BusLogic card would have allowed the system to recover,
which is one of the reasons I'm leaning in that direction. I'm much more
concerned about stability and recovery of the system as a whole than of an
individual device. My system hardware is also sufficiently error-free that I
had to attack a sacrificial CD-ROM with a Sharpie to generate these errors.
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.
Agreed. Does a DAT drive return UNIT_ATTENTION after a bus reset as the
CD-ROMs do?
Most other devices should not be that bothered by a bus reset,
except for removable disks where the door lock will be released.
I take it they don't spin down then? It appears that CD-ROMs first return
UNIT_ATTENTION and then NOT_READY, which I'm assuming is due to a spin-down
upon reset.
FWIW, this is the next thing I was planning to add better support
for after the 1.3 series gets started.
Sounds good. I'd definitely like to see a two phase reset sequence, the first
being Bus Device Reset, and the second a full SCSI Bus reset.
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.
That does sound dangerous. I'm afraid that in the cases where I can see using
that feature, it's quite likely the SCSI bus would already be too wedged to run
the special command anyway.
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.
Yes. My problem is that I seem to have *all* the possible options available to
me.
On a more positive note, I've turned on Tag Queuing in my new driver and it
seems to be working just fine in my testing so far.
Leonard
