Sense fetching [Was: cdrtools /devel ...]

[Alexander Motin]

Joerg Schilling wrote:
> Alexander Motin <mav at FreeBSD.org> wrote:
> 
>>> Compare the number of sense bytes I like to request (18) with the number 
>>> previous FreeBSD versions did actually request. It is obvious that in case 
>>> there is a resid reported onm an old kernel, libscg (with your chanhge) would 
>>> believe that probably less that the absolute minumum of sense data is available.
>> Kernel code I have changed affects only controllers without automatic
>> sense fetching. For such controllers CAM previously always reported zero
>> sense_resid, independently of requested size (which actually was also
>> ignored in this case). So previously whatever you asked for 18 or 32
>> bytes - sense_resid was always zero, like if you got full 18 or 32
>> bytes. That was wrong. Now, in the same situation, if device wants to
>> return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid
>> respectively, meaning 18 and 20 bytes of received sense.
>>
>> AFAIK sense_resid always measured from the requested sense_len. In my
>> patch for libscg you may see that I have changed both request and
>> response paths. Resulted sense_count should be absolutely the same.
> 
> What is the requested size with the various HBAs in earlier kernels?

For HBAs with automatic sense fetching -- as passed in sence_len request
field. In case of libscg it was SSD_FULL_SIZE before and I've set it to
be real value now. Returned sense_resid should be real in both cases,
respecting submitted sense_len.

For HBAs without sense fetching, CAM was always requesting SSD_FULL_SIZE
and returned fake zero sense_resid, like if it just completely fulfilled
sense_len from request. Now it should start honor sense_len on request
and return real sense_resid on reply, relative to sense_len.

-- 
Alexander Motin