>> This would tend to be much easier with new error handling. In fact
with
>> the new error handling you should be pretty much guaranteed that there
are
>> no new commands being issued while error correction is in progress. The
>> only place that commands should be issued is from the error handling
thread
>> itself
>
>And new commands?
There should be no new commands issued either. That was one of the
whole points in redoing the error handling code - any attempt to correct a
condition while commands were still coming in was bound to cause further
problems.
>> - and the easiest way of keeping the error handling thread from
>> proceeding when you are doing a bus reset is to simply not return from
your
>> dispatch function until after the delay is complete.
>
>I'd prefer to avoid this. I'll have to unlock, but this always risks a
>deadlock, if sb. else grabs the io_lock from an IRQ handler. (If it's
>properly implemented, it won't give a problem, I believe.)
If there are issues here, we need to work through them, I think. The
error handler thread is not running from the context of an interrupt
handler, so from the point of view of the mid-level it should be safe.
Given that there are no new commands being issued, the driver itself
shouldn't be re-entered via queuecommand, and given that a single instance
of the error handler thread calls the other functions you needn't worry
about re-entrancy in the error handling functions. About the only place
where you could become re-entrant is through the interrupt service routine
for the driver itself.
You could theoretically become re-entrant through one of the trivial
functions like the biosparam interface, but that isn't likely to cause any
problems.
>Anyway, what happens, if I detect a RESET on the bus (issued by another
>initiator or a device)? I also want to prevent the issueing of commands for
>a second or so, then.
This is a possibility that I guess I never really considered. Yes, a
reset can originate from a number of different places, the question is
exactly how this is relevant to the rest of the system. There is support
in there for keeping track of resets that originate from the mid-level
itself. This has a couple of consequences - if the reset originates in the
mid-level we set a flag that says we are expecting a
CHECK_CONDITION/UNIT_ATTENTION, and when we get it, we automatically retry
the command. Later on we re-lock the door for removable media.
If the reset originates elsewhere, then the
CHECK_CONDITION/UNIT_ATTENTION will arrive unexpectedly, and the unit
attention will be passed up for further processing, where it is assumed that
a media change took place.
>So, I imagine a solution, where I just don't allow commands being queued
>with queuecommand in that period of time.
>Is returning with 1 fine for new EH. Will it resent the commands later
then?
>Or is it better calling scsi_done with DID_RESET for all new commands?
>Should the latter also work with old EH?
Returning 1 from the queuecommand function will work to a point, but the
mid-level won't start queueing new commands until one of the existing
commands that is on the bus finishes. If the bus was otherwise idle and a
reset was detected, then there would be no mechanism to restart. With the
old error handling code the return value of queuecommand is not significant
(i.e. it is ignored).
Returning with DID_RESET is possible, I guess. Offhand I am not sure
what would happen if you were to do this. I would need to investigate if
you were interested.
For what it is worth, I have been toying with the idea of providing a
simple API function that low-level drivers could use to disable further
commands from being queued, and obviously to provide a second one to
re-enable them. It sounds like such a thing would be just what you would
need to solve this problem.
I suppose that a 3rd API function would also be handy where you could
report the detection of a reset that originated from elsewhere. This would
make it possible for the mid-level to treat it properly.
-Eric
----- Original Message -----
From: "Kurt Garloff" <[EMAIL PROTECTED]>
To: "Eric Youngdale" <[EMAIL PROTECTED]>
Cc: "Linux SCSI list" <[EMAIL PROTECTED]>
Sent: Wednesday, February 02, 2000 9:13 AM
Subject: Re: wait after scsi_reset
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
