On Wed, May 03, 2023 at 10:25:10AM -0400, Alan Stern wrote: > On Wed, May 03, 2023 at 03:54:45PM +0200, Oliver Neukum wrote: > > 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. I don't think we would add an other layer of aborts in front of device/LUN reset for all SCSI targets. That's just overkill for - it seems - everything but USB storage, and would slow down error recovery considerable in some cases. If this is supposed to be done in the SCSI ML, it would have to be a quirk/option IMO. -- Best Regards, Benjamin Block / Linux on IBM Z Kernel Development IBM Deutschland Research & Development GmbH / https://www.ibm.com/privacy Vors. Aufs.-R.: Gregor Pillen / Geschäftsführung: David Faller Sitz der Ges.: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294
