On 09/08/05 11:19, Alan Stern wrote:
> On Wed, 7 Sep 2005, Luben Tuikov wrote:
>
>
>>Is it possible to implement LU Reset TMF for USB storage devices?
>>If so, then you do not need to do a "bus reset".
>
>
> Sorry, I don't know that acronym. What is TMF?
Good morning Alan,
I meant Task Management Function. (SAM from T10.org, section 7).
All newer storage transports are requred to have a direct mapping
of TMFs to transport units, e.g. SAS.
>>*General note:* It is very bad to have to punish all devices on the
>>"bus" just because one device failed. Isn't there a better way
>>to recover(*) a failed USB Storage device?
>
> No. There are only two reset mechanisms available for USB Mass Storage.
I see.
> One is a class-specific reset command (which usb-storage issues when asked
> to do a device reset),
So as far as I can see it sends a reset on the wire to the device?
> and the other is a USB port reset (which
> usb-storage issues when asked to do a bus reset).
As far as I see this resets the port on the host side and then
rediscovers the devices?
> In practice, it turns out that many (perhaps even most) USB Storage
> devices don't implement the class-specific reset command correctly.
> Windows doesn't use it at all, so far as I know. This means our only
> realistic option is the USB port reset.
>
>
>>(*) That doesn't necessarily mean "bring back to life", it could
>>also mean "remove".
>
>
> Well, usb-storage doesn't need to "remove" a failed device. The SCSI core
> does a perfectly good job just by setting it off-line. And since there
> aren't other targets sharing the bus, that's good enough.
Well what happens when I just unplug the device?
>>That is, a "bus reset" means that also any other device on the "bus" is
>>unreachable. If this is _not_ the case, then a "bus" reset must _not_
>>take place.
>
> I'm not sure what that first sentence is intended to mean. The SCSI error
> handler _does_ issue bus resets even when other devices on the bus are
> still reachable, doesn't it? Provided the others are idle at the time,
> there shouldn't be any harm in it.
Ok, I see where the confusion is.
>>If you have the means to do transport checking of the state of the
>>device, (and it seems like you can for USB Storage, since it is USB after
>>all), then you _must_ implement your own eh handler. This is what
>>it is for. Please, consider.
>>
>> Luben
>>
>>P.S. It may actually simplify things in the USB transport layer _and_ in
>>SCSI Core (i.e. no need for those patches).
>
>
> We are sort of moving in that direction. usb-storage already does its
> own unsolicited resets when unexpected error occur. But we don't have
> anything like the error-handler's mechanism for recovering from timeouts
> (TUR, then device reset, then TUR, then bus reset, ...). There doesn't
> seem to be any point in reinventing all that code.
What code? What reinvention?
You _need_ to implement a timeout and eh hook if you want to do this
in any sane way.
You also need to implement kref via kobject for the devices which you/USB
Storage
represent to SCSI Core. You also need to get rid of that horrible patchwork
of a solution: dev_semaphore. Maybe you can take a look in the SAS code and
see how this is all done?
Luben
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
