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. Ben, do you know of any other good examples? > > 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. > > Putting everything together, it looks like you're asking for three new > > flags: > > > > ��� 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. > > That looks pretty fair. (Though I wish you would describe this as > being for the purpose of making Linux work as well as possible for > owners of such devices, instead of saying that it's because of my > request.) Point taken; these are your suggestions. 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. 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
