Re: Debugging scsi abort handling ?

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2014-08-25 at 13:39 +0200, Paolo Bonzini wrote:
> Il 25/08/2014 13:26, Hans de Goede ha scritto:
> > Thanks Bart and Paolo, your insights into this are greatly appreciated.
> > 
> > So with uas there are separate usb transaction for cmd, data in, data out
> > and sense for each tag. At the time of abort, usually one of data in / data
> > out and a sense usb transaction will be outstanding.
> > 
> > There already is logic in the driver to kill the data in / out transactions
> > if a sense gets returned (usually with an error) before they are done.
> > 
> > So if I'm reading this correctly, then on a successful abort, the sense
> > transaction (if not already completed by the target) should be cancelled as
> > it will never complete, correct ?
> 
> Yes.  More precisely, once the response IU comes back for the abort,
> there should be no more IUs for that task.  Figure 13 ("Multiple Command
> Example") in the UAS spec actually shows that.
> 
> At least, that's what it should be like in theory.  I suspect firmware
> bugs will abound in this area, but at least you shouldn't be actively
> expecting an IU for an aborted task.

Just a note on this.  The abort area in all devices is where we have
scope for spec compliance issues.  Also in the old days abort itself
could trigger a firmware crash on some devices (including arrays).  The
problem is actually that the system is usually groaning because it's out
of memory within the controller.  That actually means that sending in
another task (the abort) causes greater pressure.  For this reason, some
device drivers choose to skip the abort step and head straight to reset.
For reset, you guarantee that all outstanding tasks for the unit are
killed.

James