On Sat, 5 Sep 2009, Andrew Morton wrote: > OK, I reassigned it to scsi, but I expect it would help the scsi guys > if someone could add a new summary of what they think the actual bug is. Okay, here's a quick summary. This USB mass storage device has a bug: It doesn't like to access the last 16 or so sectors of LUN 0. When asked to read from those sectors it returns no data and Check Condition set. Then in response to REQUEST SENSE it returns no information (SK=0, ASC=ASCQ=0). This causes the SCSI midlayer to reissue the read request, with the same result. We enter an unending loop because each READ is a new request with a new timeout. That's the real problem -- the bug in the phone wouldn't matter much if SCSI would just give up and fail the READ after a couple of retries. There are a few more details in comment #4. Note that recently people have been encountering more and more devices with this same kind of bug (READ fails, REQUEST SENSE returns nothing). My suggestion for a fix: Don't call scsi_requeue_command() if the current command made zero forward progress. But this will have to be elaborated and made reliable. Alan Stern -- 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
