Re: libata for SATA HDs.

[Jeff Garzik <jgarzik@pobox.com>]

Timothy Thelin wrote:
>>>>>>Yes, but only if you manually apply the "libata-passthru" patch.
>>>>>
>>>>>So, why hasn't that patch got into the kernel?
>>>>
>>>>Because there are several reports of it causing problems, when used on a
>>>>loaded system.
> 
> 
>>Please post more information about these "problems".
> 
> 
>>I wonder if it might be another occurance of the libata eh lockups.
>>Those are NOT unique to ATAPI -- the lockups can happen anytime
>>the libata eh code is run, like on a busy RAID, or "loaded system"
>>suffering failed "passthru" commands.
>>
>>Perhaps kill a couple of birds with one stone, if we're lucky.
> 
> 
> I figured I should give my $.02 =)
> 
> I've noticed some bugs with the passthru implementation and have been
> working on some fixes using a custom slax live cd.  I'm in the process of
> fixing and creating multiple patches, which I was going to post to this
> list.
> 
> In particular this is what I've found so far:
> 1) The sense buffer returned when the "check condition" bit is active is
> incorrect
>    - The status and error registers values returned are the command and
> features registers sent in (they never get updated from the device after the
> command is done).
>    - The additional length field is 14 but it should be 12
> 2) The offline bit is ignored
> 3) The length fields are ignored
> 4) Not all the cdb protocols are implemented
> 
> 
> Item 1: This is trivial to fix (note that the bug also exists when
> generating the fixed length sense buffer)
> Item 2: This is important for lower level vendor commands, and its inclusion
> helps mean the difference between staying in linux or rebooting to dos.
> Companies / Users are becomming less inclined to do the latter =)
> Item 3: I don't know how important 3 is to fix considering you will have the
> scsi layer's length info in addition to the cdbs length info.  Maybe just a
> check to make sure they match, and if they don't, abort the cdb.

Feel free to send patches to fix these :)


> Item 4: Considering the passthru spec lists all the protocols, they should
> get implemented.  Otherwise apps wanting to use the passthru mechanism are
> going to be blind that protocols are not implemented.  Alternatively, there
> could be a way to (1) identify the backend is libata so it can be
> special-cased (maybe a "get version" ioctl), and (2) have a means to probe
> libata to find out what is and is not implemented at runtime (maybe extra
> information on the "get version" ioctl).

I would prefer simply to implement all the protocols.  For protocols 
which transport reset-style mechanisms such as SRST, this may take some 
work over and above simply issuing the command to the device.  You may 
need to re-issue IDENTIFY DEVICE, quiesce the bus, etc.

	Jeff