On Wed, 2012/5/9, Alan Stern wrote: > On Tue, 8 May 2012, Norman Diamond wrote: >> Alan Stern wrote: >>> On Tue, 8 May 2012, Norman Diamond wrote: >>>> In my case there is no other way that a host (PC or other, any OS or >>>> driver) could obtain a reported capacity past the 2.2TB mark. >>>> Sometimes I guess a USB-to-[S]ATA bridge might obey ATA passthru of >>>> an ATA Identify command though I haven't seen one. >>> >>> There definitely are some bridges which handle ATA passthru correctly. >> >> Oh, please can you suggest some. I search occasionally but have >> never found one that was described as obeying ATA passthru. Of >> course I can't command my users to use such bridges, but I would like >> to use one or two. > > The only ones I'm aware of are the entries marked with the SANE_SENSE > quirk in unusual_devs.h: the HP Personal Media Drive (03f0:070c), the > Genesys Logic bridge (05e3:0723), the Seagate FreeAgent Pro > (0bc2:3010), the Maxtor bridge (0d49:7310), the Western Digital bridge > (1058:0704), and a different JMicron bridge (152d:2329). Of course, > the fact that the flag is set doesn't necessarily mean the device > really does have SAT support. Among those, the Genesys and JMicron ones look like they have a chance of being used in adapters sold separately from Seagate and Western Digital external drives. By any chance do you know of cables or docking stations that use them? >>> Except that READ CAPACITY(16) might cause some buggy devices to crash. >> >> Instead of rejecting the command as not handled? > > Exactly. For example, it wouldn't be surprising if quite a few flash > drives crashed upon receiving that command. Considering that READ CAPACITY(16) has additional reasons for existing besides increased capacity, I hoped every manufacturer would be prepared to expect it, even if they reject it. Sigh. >>> CAPACITY_10_AND_16: Issue both READ CAPACITY and READ >>> CAPACITY(16), and if READ CAPACITY(16) gives a result > 2 TB >>> and READ CAPACITY doesn't give 0xffffffff, truncate the size to >>> 2 TB; >>> >>> CAPACITY_HEURISTICS_63: Don't decrement the capacity if >>> the reported capacity is a multiple of 63, but otherwise behave >>> like CAPACITY_HEURISTICS; >>> >>> TEST_CAPACITY: Try to do a single-block read of the last >>> reported block. > > What I'm wondering is whether it's appropriate to have three separate > flags for these things, or whether some subset of them should be > controlled by the same flag -- maybe a flag that would be set only for > devices that are known to be bridges. They are three separate operations, and you've pointed out there's a chance that some devices might crash on some of them and not others, so it would be a good idea to make three separate flags. -- 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
