From: David Laight
>
> From: Norman Diamond
> ...
>> By the way, I've seen some USB bridges that lie about whether they
>> performed various SAT commands (ATA passthrough), but told the truth
>> about performing an ATA IDENTIFY DEVICE through SAT. So we could
If READ_CAPACITY_10 returns something that looks valid but might be off
by a multiple of 2TB, and READ_CAPACITY_16 fails, what do we really want
to do when we read the partition table?
If the partition table indicates that everything fits in the capacity
returned by READ_CAPACITY_10, great, it is
Kernels somewhere around 2.6.35 could handle USB 3.0 at random sometimes,
but kernel 3.8.0 fails consistently. I know I should try to bisect this,
but I don't have time and the randomness of the older kernel doesn't help.
lspci:
0d:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Hos
Robert Hancock wrote:
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:
Sometimes I guess a USB-to-[S]ATA bridge might obey ATA passthru of
an ATA Identify
Sorry. I'll try to post it to the correct mailing list this time.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
If I understand the standard correctly, if SECURITY ERASE UNIT fails to erase a
bad block then the result should have the ABRT bit set.
There are some kinds of operations where a drive might set IDNF instead of
ABRT, but if I understand correctly, SECURITY ERASE UNIT is not one of them.
In one
