[195] in linux-scsi channel archive
Re: SCSI Reset Functions.
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Mon May 22 11:40:43 1995
From: "Eric Youngdale" <eric@aib.com>
Date: Mon, 22 May 1995 10:27:45 -0400
In-Reply-To: "Leonard N. Zubkoff" <lnz@dandelion.com>
"SCSI Reset Functions." (May 22, 12:30am)
To: "Leonard N. Zubkoff" <lnz@dandelion.com>
Cc: linux-scsi@vger.rutgers.edu, drew@boulder.openware.com
On May 22, 12:30am, Leonard N. Zubkoff wrote:
> Yes, I agree. Another concern I have had is with cache
> coherency for caching controllers and the cache on disk drives that do
> write caching. If putting a cdrom in the drive that has been written
> on with a sharpie marker corrupts the hard drive (same goes for a tape
> with a bad spot on it), then I would rather not do it at all rather
> than do it wrong. To put it another way, it needs to be carefully
> thought out first.
>
> Indeed. My present temporary strategy has been to implement and test
three
> options as well as I can (controlled by #ifdef's in the source): (1)
performing
> a Host Adapter Hard Reset which also causes SCSI Bus Reset, (2) Sending
Bus
> Device Reset to the single Target having problems, and (3) doing nothing
and
> hoping for the best (what the current driver does). I have chosen (1) as
the
> default, as I'm more concerned with keeping my system up and running than
> leaving a failing CD-ROM still accessible. I can always reboot cleanly
and
> quickly as long as the basic disk I/O is working.
When I first started thinking about this, I had no knowledge about
what cacheing controllers really do. From what I gather, the idea is that
writes go to the controller and are written as soon as possible. Same
goes for the cache on the drive. I understand that DTP controllers
with a cache do not flush the cache when a hard reset is requested.
This is something that each driver author needs to keep in mind.
> By the way, how safe or unsafe is enabling write caching? I've noticed
that
> scsi-config warns against this, but I have no real information on whether
or
> not enabling write caching is a good idea. What are the dangers of doing
so?
> Assuming no power failures or a working UPS, is there any real danger?
Again, this is something that I am not entirely sure about. The
SCSI docs suggest that in the event of drive or power failure that not all
data
would be written to disk - I suspect that with a UPS you would probably be
safe.
> Who knows whether the higher level parts of the SCSI Subsystem are able to
take
> full advantage of tag queuing, though, as they've never been tuned for it.
> Once I'm happy with the robustness of the driver, I plan to investigate
further
> the pattern of commands the driver is being handed, issues of
scatter/gather
> limits, etc. For example, the current strategy of a single cmd_per_lun
value
> seems to be a limitation, I would think. A fast disk could reasonably
have
> many commands queued whereas ther's not much point in that for a slow
CD-ROM.
The basic idea that I had was that to take advantage of tagged
queueing, you merely increase the number of outstanding commands per lun
that the driver supports. The upper level code just keeps feeding commands
to
the board, and the board itself is responsible for tagging the actual
commands. For DPT boards this strategy seems to work, since Michael said
that he had to increase the number of commands per lun to 64 to get optimal
performance. You have to be aware of memory usage problems in this case -
if the board emulates a 1542, you would not want this that high if you had
more than 16 Mb, for example.
> Indeed. It would also be good if the precise options available to the
author
> of a driver were explained somewhere. I've done my best based on reading
the
> comments and looking at some of the other drivers, but I still wouldn't
say I
> really understand this area completely.
Yeah, I know. The details have always been a bit fuzzy, and we
have really only defined things once we start using a particular part of the
interface.
> Exactly. If I'm going so far as to reset the bus, I figure I might as
well
> give the card a hard reset as well just in case there's anything wedged.
So
> driver authors will need to have all possibilities available, and a way to
> indicate what they've chosen to do.
This is sort of what some of the SCSI_RESET_* options are for. For
example, SCSI_RESET_SUCCESS indicates that all of the outstanding commands
for the bus have automatically been restarted, so that we do not need to
do anything. SCSI_RESET_PENDING indicates that the outstanding commands
have not been restarted, and the mid level code should restart all commands
that were on the bus. Even then, I think the meaning of the various
options needs to be spelled out a bit more so that each one has a very
precise meaning.
For the sake of argument let us say that the interface to the
reset() function were changed to take an additional parameter which
would indicate how severe a reset we are asking for. We then will need
to create a table of return values for the reset function which would
indicate the action taken. Currently we have:
BUS DEVICE RESET:
-----------------
SCSI_RESET_SNOOZE: Don't know how to do this - just wait it out.
SCSI_RESET_PUNT: Don't know how to do it - request sense info to decide
how to proceed.
SCSI_RESET_SUCCESS: Device reset, command was restarted. Nothing more to
do
SCSI_RESET_PENDING: Device reset, command not restarted. We expect an
interrupt to tell us that the reset took place.
SCSI_RESET_WAKEUP: Reset took place - mid level needs to request sense info
to decide how to proceed.
SCSI_RESET_ERROR: Something went wrong.
For the hard reset option, we can reuse some of the same status codes,
plus we may need to add some more. Here are some preliminary suggestions
for the meanings of the return codes.
BUS RESET:
-----------------
SCSI_RESET_SNOOZE: Don't know how to do this - just wait it out.
SCSI_RESET_PUNT: Don't know how to do it - request sense info to decide
how to proceed. This will end up attempting to requeue
the command, provided that we are successful in obtaining
the sense information.
SCSI_RESET_SUCCESS: Bus reset, all outstanding commands were restarted.
No interrupts expected, nothing more to do. Use
this when
the host adapter keeps track of all outstanding commands
and automatically restarts all of them.
SCSI_RESET_PENDING: Bus reset, command not restarted. We expect an
interrupt for each outstanding command to tell us that the
reset took place. Use this option if the host
adapter
keeps track of outstanding requests and sends a message
indicating a reset took place for each one.
SCSI_RESET_WAKEUP: Reset took place - mid level needs to request sense info
to decide how to proceed. No commands restarted by
low-level. Use this if the host adapter
memory is flushed
by the reset operation, and requires the mid-level code
to restart all commands on the bus.
SCSI_RESET_ERROR: Something went wrong.
My question is, are there other things that need to be reported, and are the
above descriptions sufficiently descriptive?
-Eric
--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."
