Alan Stern wrote:
> On Wed, 25 Jun 2008, matthieu castet wrote:
>
>> Alan Stern wrote:
>>> On Wed, 25 Jun 2008, matthieu castet wrote:
>>> return 1;
>>>
>>> I suppose we could check for the US_SC_CYP_ATACB code and use a 22-byte
>>> REQUEST SENSE instead of 18-byte. Would that solve the problem? And
>>> would it be safe?
>>>
>> But in this case it isn't US_SC_CYP_ATACB but a normal usb storage device.
>>
>> I am sure it isn't US_SC_CYP_ATACB, because unless something really bad
>> happen, it write 0 to ATA_Descriptor[4] and never 0x50.
>
> In that case, how is usb-storage supposed to know when to use 22 bytes
> and when to use 18? We can't just use 22 all the time; there are
> devices that will die instantly if they get a REQUEST SENSE command
> with any length other than 18.
>
I don't know. That what I always said Sat can't be done on 'raw'
usb-storage.
But western digital seems to have done an implementation.
May be they have more info on this, if someone have a contact...
Matthieu

On Wed, 25 Jun 2008, matthieu castet wrote:
> Alan Stern wrote:
> > On Wed, 25 Jun 2008, matthieu castet wrote:
> > return 1;
> >
> > I suppose we could check for the US_SC_CYP_ATACB code and use a 22-byte
> > REQUEST SENSE instead of 18-byte. Would that solve the problem? And
> > would it be safe?
> >
> But in this case it isn't US_SC_CYP_ATACB but a normal usb storage device.
>
> I am sure it isn't US_SC_CYP_ATACB, because unless something really bad
> happen, it write 0 to ATA_Descriptor[4] and never 0x50.
In that case, how is usb-storage supposed to know when to use 22 bytes
and when to use 18? We can't just use 22 all the time; there are
devices that will die instantly if they get a REQUEST SENSE command
with any length other than 18.
Alan Stern

Alan Stern wrote:
> On Wed, 25 Jun 2008, matthieu castet wrote:
> return 1;
>
> I suppose we could check for the US_SC_CYP_ATACB code and use a 22-byte
> REQUEST SENSE instead of 18-byte. Would that solve the problem? And
> would it be safe?
>
But in this case it isn't US_SC_CYP_ATACB but a normal usb storage device.
I am sure it isn't US_SC_CYP_ATACB, because unless something really bad
happen, it write 0 to ATA_Descriptor[4] and never 0x50.
Ian what's your linux kernel version ($ uname -a) and usb id of your
device ($ lsusb).
Matthieu

Hi,
Ian E. Morgan wrote:
> I have a Western Digital "My Passport Essential 320GB". It is a WDC
> WD3200BEVT-22ZCT0 drive, and the enclosure seems to be smart enough to
> use a SATL for native command passthrough.
> I was very please to find the recent CVS smartmontools able to monitor
> this drive with it's support for SAT. However, there is one glitch.
> Everything works just fine except for the -H command, which generates
> an error, so a -a also requires a -T permissive to ignore the error
> and continue.
>
usb storage can't support SAT check condition feature (at least with
standard stack).
So it means CHECK_POWER_MODE,STATUS,STATUS_CHECK shouldn't work. And it
seems it is what you are seeing.
If you look at the sense buffer [1] you can see that byte 18-22 are 0.
And if you look at the smartctl test, it wants 0x4f at ATA_Descriptor[9]
or sense byte 17 (you've got it), but you miss
ATA_Descriptor[11]/sense byte 19.
This is because the linux stack only request sense of size 18. May be if
the linux stack was requesting a bigger sense, everything could work
with your drive.
But Alan Stern said
(http://article.gmane.org/gmane.linux.usb.general/2098) usb storage are
no way to know the size of the sense.
I CC Alan Stern and usb storage maintainer as they could be interested.
[1]
>>> Sense buffer, len=22:
00 72 00 00 00 00 00 00 0e 09 0c 00 00 50 00 00 00
10 c2 4f 00 00 00 00
status=2: [desc] sense_key=0 asc=0 ascq=0
Values from ATA Return Descriptor are:
00 09 0c 00 00 50 00 00 00 c2 4f 00 00 00 00
[2]
if (STATUS_CHECK == command) {
if ((ardp[9] == 0x4f) && (ardp[11] == 0xc2))
return 0; /* GOOD smart status */
if ((ardp[9] == 0xf4) && (ardp[11] == 0x2c))
return 1;