>>>>> 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. 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). Btw I have not experienced any stability issues with the passthru implmentation, just bugs or missing implementations. Thanks, Tim Thelin - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
