===== DO NOT PATCH IT THIS WAY! ===== --- On Fri, 2012/5/4, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 3 May 2012, Norman Diamond wrote: >> Alan Stern wrote: >>> On Thu, 3 May 2012, Norman Diamond wrote: >>>>> It looks like the bridge is sending just the least-significant 32 bits >>>>> of the capacity. What it should have done is reply with 0xffffffff. >>>>> Then the kernel would know to try again with a READ CAPACITY(16) >>>>> command, which is capable of retrieving values larger than 32 bits. >>>> >>>> You are right, bridges' failures to reply with 0xffffffff are >>>> bridges' bugs. Obviously Windows proceeded to try a READ >>>> CAPACITY(16) regardless. >>> >>> Don't be so sure. 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. 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). 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. It looks to me like Windows 7 will happily write overlapping partitions in these cases. For the first time in history, overlapping partitions will be the fault of hardware instead of Windows. -- 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
