On 03.05.23 14:51, Benjamin Block wrote:
usb-storage can do a reset only on the USB device level,
which translates to a bus reset on the SCSI level.
And we are supposed to cancel any communication with the device
before that.
Is that a limitation of the devices or drivers? Because then you don't
match SCSI semantics for LU reset - which aborts all running commands
We do not support a LUN reset. That's a limitation of the protocol.
If something goes wrong you need to reset the whole USB device, which
corresponds to a host adaptor on the SCSI level.
on that scope among things. Which might explain the reason/choice behind
this unexpected behavior for you.
For the device a reset presumably does wipe out the command currently
under execution. The problem is within the driver. It thinks that
a command is still active. And we are limited to one command at a time
(on the whole bus - again protocol limitation)
On random thought I had: in theory you could implement your own EH
strategy handler if the default one doesn't work for you. ATA and SAS do so.
[drivers/scsi/scsi_error.c:2285 `shost->transportt->eh_strategy_handler()`]
This can re-use parts/all of the existing escalation sequence in
`scsi_eh_ready_devs()`.
But that's no short-term fix.
That looks like using a sledge hammer.
Regards
Oliver
