Re: Debugging scsi abort handling ?

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 08/25/2014 09:20 AM, Paolo Bonzini wrote:
> Il 23/08/2014 16:52, Hans de Goede ha scritto:
>> Hi All,
>>
>> Now that the UAS driver is no longer marked as CONFIG_BROKEN,
>> I'm getting quite a few bug reports about issues with UAS drives.
>>
>> One if the issues is that there might be a number of bugs in the
>> abort handling path, as I don't think that was ever tested properly.
>>
>> So I'm wondering is there a way to test the abort path with a real
>> drive? E.G. submit some command which is known to take a significant
>> amount of time, and then abort it right after submitting ?
> 
> You could have some luck with QEMU's UAS emulation.  If you set QEMU's
> I/O throttling options low enough (e.g. 100KB/sec), and then use dd with
> iflag=direct and a largish block size (a few MBs), the guest should
> abort its I/O soon enough.

Thanks for the suggestion, that is an interesting idea. The problem is
though, that qemu's uas implementation is modeled after the kernel
uas driver (including some bugs which I've ended up fixing at both ends),

I want to see how real hardware deals with abort commands (e.g. does it
only acknowledge the abort, or does it also sends a sense code for
the actual command).

Regards,

Hans