Alan Stern 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 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. There is no contradiction. I observed that Windows saw the asserted size of the partition, and that Windows used the accessible area of the partition when such use was not prevented by truncation at the drive's reported capacity. When Windows needed to access the trailing sectors of the partition but they were inaccessible due to the drive being smaller, Windows did not mount the partition. Now this part of it is my experience, but you don't cite contradictory reports on this. >> 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. We know that it didn't come from READ_CAPACITY(10), and we know that it didn't come from believing the partition table. When the same drive was connected through an incredibly stupidly broken adapter, Windows saw the partition table near the beginning of the drive, could not access the mirror of the partition table (GPT) at the end of the drive, and displayed the physical drive size that the incredibly stupid broken adapter reported (the infamous size 2.2TB). A partition table, whether accurate or not, does not overcome the physical size that any OS can access. > 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 before, the live Linux system that I use is very painful to update. I suppose I'll look for a PC to install an installable version and rebuild the kernel there. >> 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. Well yeah some versions of Windows can't see more than 504MB regardless, or can't see more than 32GB regardless, or can't see more than 137GB regardless. How about if we ignore those? (Except, let's laugh at Windows 3.1 that divided by zero while trying to format the second partition on a 1GB drive ^_^) Yes it depended on the partition type because FAT16 doesn't have part of its structure mirrored in trailing sectors. Also again it depends on some versions of Windows because the non-NT series couldn't natively access NTFS partitions. Nonetheless, no matter how much Windows believes a partition table, it cannot access sectors that a drive's DCO or a broken adapter prevent access to. >> 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. That's good. > 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). That's bad. Your failing one is indistinguishable from mine which I still think must be working. > 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. But that test was only for curiosity. TEST_CAPACITY only needs to try to read the last single block that is asserted to exist; it doesn't need to read a collection. -- 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
