I've been thinking some more about this. Although the driver is apparently at fault here by issuing a reset without telling the mid-layer, it might be useful to filter out other common ASC/ASCQ codes in scsi_io_completion() we retry on "in the process of becoming ready", then for any other UNIT_ATTENTION, we assume it was a disc change for removable (this is what causes the I/O error in this case) or a reset for non-removable.
Perhaps we should do a more dilligent check for the reset case? ASC 0x29 and ASCQ <= 4 seems to identify all the reset cases. Since the tape case doesn't come through here, there's no danger of doing an incorrect retry for it. There is, however, one danger to the removable case: a power cycle could still be accompanied by a medium change, which would now be missed. On the whole, I'm inclined to leave everything the way it is, but was wondering if there were any other comments? James ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
