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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
