[EMAIL PROTECTED] said:
> I tried to add some logic to the mid level driver [core] so that the
> upper level drivers (specifically sg under superuser's instruction)
> could request a SCSI bus/device/host reset. Basically the patch was
> rejected because it might interfere with the mid level's error
> processing.
We really need to modify the mid level's attitude to resets, otherwise we're
going to get killed on fibre channel (which is basically a huge
multi-initiator environment). Once you have more than one initiator on a bus
(or SAN ring) a reset can come at any time or stage during command processing
(Linux actually exacerbates the situation by sending a reset on boot).
Probably the way to hande this is some type of reset notify callback from low
to mid layers. Drivers can detect bus resets directly. Device or LUN resets
can be detected by unexpected Unit Attention conditions. At the moment
external reset handling is done at the low level. Nice drivers (like the
aic7xxx, sym8xx and most fibre drivers) detect resets and UA's, abort
outstanding commands and return them to the mid level. Cards which handle
reset processing correctly also correctly handle reset injection without
causing problems to the mid level.
Given the above, I really think it makes sense to provide a reset injection
ability through the sg driver on a "caveat emptor" basis. If you have a low
level driver that doesn't do reset processing, the chances are that the mid
level error handling will get very confused. However, for a (reasonably long)
list of cards reset injection will work correctly. Since reset injection is
an essential facility for handling reservations in a SAN environment, I don't
think it's necessary to reject it just because of a few bad low level drivers,
just take the standard UNIX philosophy of letting root decide if it's safe or
not.
> My feeling is that in some contexts [best known to a user application
> or an upper level driver] turning off the mid level's error processing
> might be advantageous. There is also no way for an application or an
> upper level driver to abort a SCSI command in progress. This means
> that an application can't set an extremely long timeout to the SCSI
> subsystem, run its own timer, and if that timer expires, abort the
> outstanding command.
That would be truly great and useful functionality!
James Bottomley
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
