On 14-08-23 10:52 AM, Hans de Goede wrote:
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 ?
Hi,
You might experiment with starting a streaming read
from one shell (e.g. with dd or ddpt) and while that
is underway, from another shell issue a
'sg_reset --device' and see what happens. If nothing then
try 'sg_reset --target'.
Aborting a single, long duration command from the user
space (and only that command, assuming other processes might
be using that disk) is not easy to do.
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
