Date: Mon, 08 Nov 2010 18:23:22 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] Message-ID: <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4CD82E2A.3070407@FreeBSD.org> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Motin <mav@FreeBSD.org> wrote:
> > Your patch to libscg looks definitely OK if we only look at the new corrected
> > kernel driver behavior.
> >
> > There is a problem:
> >
> > In case that there is a sense data residual > 0, libscg will asume that there
> > is less sense data that really present in case that a "new" libscg is runnung
> > on an old kernel.
> >
> > 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.
> > I see no advantage in removing the call to fillbytes().
>
> scgcheck tests how much sense data received by counting 0x00 and 0xff
> bytes. Zero-filling response buffer breaks that check. Though I have no
> idea if other crdtools' applications depend on these zeros. There could
> be some internal inconsistency.
O, I need to check other low level transport adaptation layers and think about
this statement.
> > Did you test a modified libscg on an unmodified kernel?
>
> Unmodified kernel by default doesn't return any sense data at all for
> new CAM-based ATA -- this changes should be invariant. New scgcheck runs
> same bad as old. It just can't become worse. :)
>
> Legacy atapicam wrapper ignores sense_len on input and doesn't fill
> sense_resig on output -- I haven't tested, but it also should be invariant.
I am not only talking about ATAPI but abut SCSI in general.
Do you know the CAM behavior for other SCSI transports?
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling>