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

Joerg Schilling Joerg.Schilling at
Thu Nov 11 10:05:40 UTC 2010

Alexander Motin <mav at> wrote:

> >>> Given the fact that many drives will probably only return 18 bytes of sense 
> >>> data, this will happen every time libscg is told to fetch more sense than the 
> >>> drive is willing to return.
> >>>
> >>> Is there a way to distinct an old kernel from a new one?
> >> I don't see the problem. Previous kernel in most cases reported
> >> sesnse_resid == 0, lying that there is more sense data then really is.
> >> New one should report real (often positive) value. In both cases
> >> sesnse_resid value measured from the value submitted to the kernel.
> > 
> > Did the old kernel return  a zero sense_resid for any implemented SCSI 
> > transport? Libscg is a generic SCSI transport library and cdrecord is just one 
> > user of this lib.
> Not sure I understand your question. Zero sesnse_resid is absolutely
> normal situation if device gave same amount of sense as application
> requested. As I can see, many of SCSI controllers report sesnse_resid
> properly. I may assume that some, like atapicd don't -- in that case
> you'll also see 0 there.

FreeBSD-CAM did try to fetcth more than 18 bytes of sense data and it may be 
that some drives did return only 18 bytes. In this case, I would asume that 
there is a resid > 0.

> > Do you know the CAM behavior for other SCSI transports?
> I don't have real SCSI CD to test, but a as I can see, most of SCSI
> controllers return sense data automatically. Sense fetching changes
> should not affect/break anything there.

The question still remains whether the previous implementation did return resid 
> 0 in some cases. In this case, I would need to implement both variants in the 
libscg adaption layer and I would need to know whether I am running on an old 
version or on a new version kernel. Do you know of a simple method to implement 
this distinction?


 EMail:joerg at (home) Jörg Schilling D-13353 Berlin
       js at                (uni)  
       joerg.schilling at (work) Blog:

More information about the freebsd-stable mailing list