We do have a problem with infinite retry loops. I'm not sure which kernels are affected, but there's a good chance 2.6.27 is and an excellent chance that 2.6.28-rc1 will be. The problem is caused by buggy USB devices that return the number of sectors in response to READ CAPACITY, rather than the highest sector number. Thus they appear to have one more sector than they really do. We can create blacklist entries for these devices, but they constantly appear and the list is never up-to-date. So we need to handle them robustly even when they aren't on the blacklist. When the system tries to read the non-existent last sector, the devices send back no data. In addition, the stupid devices return no sense information (even though they often do return Check Condition status). The question is: What should usb-storage report to the midlayer when this happens? Setting scmd->result to DID_ERROR doesn't help, because sd_done() sets it back to 0 in the NO_SENSE case. We end up calling scsi_end_request() with error = 0 and bytes = 0, thereby requeuing the request. There's no counter to limit the number of times the same request can be requeued. I actually saw this happen to somebody in the log accompanying a bug report a few days ago (Bugzilla #11768). What's the proper solution? Should usb-storage make up some bogus sense data (HARDWARE_ERROR sense key maybe)? Alan Stern P.S.: What about my proposed changes to scsi_io_completion()? There hasn't been any response. -- 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
