Hi all, I also have one "JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge (152d:2338) Sadly, i do not have any 3 tb hard disk. If there is something i can do to help with the quirks handling of these devices, please tell. I just tested with a spare old hdd, with no important data. I have other bigger hard disks. # sg_raw -r 32 /dev/sg2 9e 10 0 0 0 0 0 0 0 0 0 0 0 20 0 0 SCSI Status: Good Sense Information: sense buffer empty Received 32 bytes of data: 00 00 00 00 00 0d f9 4b af 00 00 02 00 00 00 00 00 ......K......... 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ usb 1-2: new high speed USB device using ehci_hcd and address 5 usb 1-2: configuration #1 chosen from 1 choice scsi13 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 5 usb-storage: waiting for device to settle before scanning Vendor: WDC WD12 Model: 00JS-00MHB0 Rev: Type: Direct-Access ANSI SCSI revision: 02 SCSI device sdc: 234441648 512-byte hdwr sectors (120034 MB) sdc: Write Protect is off sdc: Mode Sense: 28 00 00 00 sdc: assuming drive cache: write through SCSI device sdc: 234441648 512-byte hdwr sectors (120034 MB) sdc: Write Protect is off sdc: Mode Sense: 28 00 00 00 sdc: assuming drive cache: write through sdc: sdc1 sdc2 sdc3 sdc4 < sdc5 sdc6 sdc7 sdc8 > sd 13:0:0:0: Attached scsi disk sdc sd 13:0:0:0: Attached scsi generic sg2 type 0 usb-storage: device scan complete Cheers. On Fri, May 4, 2012 at 11:27 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 4 May 2012, Norman Diamond wrote: > >> 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. > > Sure, that's what Windows did during your test. But you have no direct > way of knowing what happened during tests reported years ago by people > using other versions of Windows. > >> 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. > > I can't cite them because I haven't tried to try tracking them down in > the mailing list archives (not an easy task at best). Still, as far as > I can remember, the reported experiences _did_ contradict what you > observed. However I don't want to make any strong claims, because my > memory _is_ fallible. Mainly I just want to point out that some of > what you claim as fact is really inference and jumping to conclusions > on insufficient evidence. > >> >> 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 > > You don't "know" these things -- you infer them from the observed > behavior. > >> 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. > > That wouldn't necessarily prevent Windows from allowing a partition to > be mounted even though it extended beyond both the reported end of a > device and the physical end, particularly if the filesystem on that > partition did not have important data structures stored at the end. > >> > 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 ^_^) > > I wasn't referring to those systems anyway. > >> 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. > > That is obvious and irrelevant to our discussion. > >> > 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. > > It may be a function not of the bridge but of the drive connected to > the bridge. I don't have any drives to test that are > 2 TB. > > You should test your bridges with sg_raw, if you can't easily build a > new kernel. The command to use is: > > sg_raw -r 32 /dev/sgX 9e 10 0 0 0 0 0 0 0 0 0 0 0 20 0 0 > > (16 bytes total in the CDB, and fill in the X with the appropriate > number). > >> > 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. > > Well, one of the collections I tested was a singleton, consisting of > nothing but the one block following the the physical end of the drive. > > 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 -- 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
