On 05/08/2012 06:12 PM, Norman Diamond wrote:
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?
I have a Vantex NexStar TX 2.5" SATA enclosure that uses:
Bus 001 Device 006: ID 152d:2329 JMicron Technology Corp. / JMicron USA
Technology Corp. JM20329 SATA Bridge
and ATA pass-through seems to work (at least as far as commands like
hdparm -I and smartctl).
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-u79uwXL29TY76Z2rM5mHXA@xxxxxxxxxxxxxxxx
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
