On Wed, May 03, 2023 at 03:54:45PM +0200, Oliver Neukum wrote: > 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. There is the Bulk-Only Mass Storage Reset request, which is what usb-storage issues when asked to perform a device reset. But few devices implement it correctly. > > 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. I think the best answer is to accept the patch that started this email thread, perhaps with a minor change. The driver can easily abort the currently running command (if any) on its own before starting a reset. Alan Stern
