On Mon, 7 May 2012, Norman Diamond wrote: > ===== > DO NOT PATCH IT THIS WAY! > ===== I wasn't going to. :-) That was just for purposes of testing. > I am pretty sure that Windows XP did not try a READ CAPACITY(16) in > that case but Windows 7 did. I cannot be completely sure because I > found two free USB snoopers, one of which worked on Windows XP but is > documented as not working on Windows 7, and one of which didn't even > work on Windows XP or at least did not work as documented. But it > doesn't matter. At least two broken bridges are broken worse than > that. > > Quoting your proposed patch for the purpose of discussion: > > > Index: usb-3.4/drivers/scsi/sd.c > > =================================================================== > > --- usb-3.4.orig/drivers/scsi/sd.c > > +++ usb-3.4/drivers/scsi/sd.c > > @@ -1902,7 +1902,7 @@ static int sd_try_rc16_first(struct scsi > > ��� ��� return 1; > > ��� if (scsi_device_protection(sdp)) > > ��� ��� return 1; > > -��� return 0; > > +��� return 1; > > } > > > > /* > > > > > > That accords with what I think Windows does. Is that just your guess or do you have evidence for it? You said that Windows XP doesn't use READ CAPACITY(16), which means it is certainly not in accord with the patch. And you said that the USB snooping programs didn't work right under Windows 7, which means you don't know what Windoes 7 actually does. > But broken bridges look pretty broken. I'm guessing upon guessing > again, but it looks like some broken bridges respond correctly to > READ CAPACITY(16), wrap around instead of responding correctly to > READ CAPACITY(10), AND: wrap around instead of responding correctly > to READ(16). Just because a bridge can handle 3TB for READ > CAPACITY(16) doesn't mean it can handle that for READ(16) or > WRITE(16). Very broken indeed. How did you determine this? > I have a feeling we have to do both READ CAPACITY(10) and READ > CAPACITY(16), and if we see wraparound then we should either truncate > the drive to 2.2TB or avoid the drive entirely. I think truncation > is safe enough at this point -- if a partition gets truncated then > subsequent attempts to mount will fail, so any existing but > inaccessible data will be safe from harm, while accessible data will > be read and written correctly. That sounds like the best approach. You would want to do this for all USB drives? Or only those known to be (S)ATA bridges? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
