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 have seen reports from others indicating quite > > clearly that Windows would believe a partition table even when it > > contradicted a device's reported capacity. > > Yes, but Windows didn't see the entire asserted partition, Windows > saw the reported size of the drive and the asserted size the > partition and the accessible area of the partition. Presumably you are referring here to your own experience rather the reports from others mentioned above. > In the test mentioned here, Windows saw the entire drive size, which > had to come from READ CAPACITY(16). Perhaps so. I'd feel a lot more confident about that conclusion if there was a USB trace. Speaking of which, at the bottom of this email is a test patch that will cause Linux to always try READ CAPACITY(16) before READ CAPACITY. Let's see what it does with your drive. You don't need to post more than first 200 lines of the resulting usbmon trace; that's where the interesting stuff will be. > As mentioned earlier in this thread, in an earlier test I had taken a > drive that had an NTFS partition and had subsequently been DCO'ed > down to a size that truncated the NTFS partition. Windows saw the > drive's reported size, saw the partition table, and refused to mount > the partition. In that situation the DCO had cut off part of the > NTFS structure that is mirrored at the end of the partition so > Windows knew that the partition was not properly accessible. Different versions of Windows may behave differently. It might also depend on the partition type -- it may even depend on the drive attached to the bridge. > >>� I hope old bridges that can't handle READ > >> CAPACITY(16) at least avoid crashing when presented with that > >> command, so a workaround could always send that command.� Or a quirk > >> could be added to say which bridges crash.� If a bridge sends an > >> ordinary rejection saying that it can't handle the command but > >> doesn't crash, then there's no need to avoid the attempt. > > > > You can try sending the command yourself using sg_raw, to see how well > > your bridges handle it. > > I think we have enough evidence that mine handle READ CAPACITY(16). A usbmon trace using the patch below ought to tell us for sure. > For bridges older than mine, we don't even need to worry if they > reject a READ CAPACITY(16) but survive to continue the kinds of > operations they ordinarily perform; we only need to worry if they > crash when commanded to READ CAPACITY(16). That's right. You'll be happy to hear that my Prolific bridge responds with an Illegal Request error code. That's with a rather old drive which can hold only 80 GB. I also tested my JMicron bridge. It has the same vendor and product IDs as yours (152d:2338). It doesn't have the capacity bug. It does not recognize READ CAPACITY(16) (fails with Illegal Request). When asked to read a collection of blocks any of which extend beyond the end of the drive, it returns immediately with no data and no error indication -- which obviously is not ideal but it's better than hanging. Alan Stern 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; } /* -- 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
