From owner-freebsd-current@FreeBSD.ORG Wed Jan 28 02:53:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DD2016A4CE for ; Wed, 28 Jan 2004 02:53:47 -0800 (PST) Received: from e0-a3.b1.lan.prg.vol.cz (e0-a11.b1.lan.prg.vol.cz [195.122.204.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE15843D53 for ; Wed, 28 Jan 2004 02:53:44 -0800 (PST) (envelope-from pav@FreeBSD.org) Received: from pav.hide.vol.cz (localhost [127.0.0.1])i0SArQI5075703; Wed, 28 Jan 2004 11:53:26 +0100 (CET) (envelope-from pav@FreeBSD.org) Received: (from pav@localhost) by pav.hide.vol.cz (8.12.10/8.12.10/Submit) id i0SArA2d075620; Wed, 28 Jan 2004 11:53:10 +0100 (CET) (envelope-from pav@FreeBSD.org) X-Authentication-Warning: pav.hide.vol.cz: pav set sender to pav@FreeBSD.org using -f From: Pav Lucistnik To: Harti Brandt In-Reply-To: <20040128110230.A3524@beagle.fokus.fraunhofer.de> References: <1075254712.2786.42.camel@itouch-1011.prv.au.itouchnet.net> <20040128110230.A3524@beagle.fokus.fraunhofer.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-d7mP70tQosXEgiKxuo17" Message-Id: <1075287190.46456.7.camel@pav.hide.vol.cz> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 28 Jan 2004 11:53:10 +0100 cc: Andrew Thomson cc: freebsd-current@FreeBSD.org Subject: Re: atapi cdrecord under 5.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: pav@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2004 10:53:47 -0000 --=-d7mP70tQosXEgiKxuo17 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable V st, 28. 01. 2004 v 11:07, Harti Brandt p=ED=B9e: > That may be the same problem I discovered yesterday together with Joerg > Schilling (the cdrecord author). According to him, for several kinds of C= D > recorders error returns from the recorder are expected by cdrecord (some > recorders, for example, return an error for long writes, although they > process it (this is allowed by the SCSI spec)). cdrecord handles these > error (and they do not turn up as errors to the user), but in order to do > this it expectes the CAM layer to return correct sense data after an erro= r > (the CAM spec requires the CAM layer to automatically issue a SENSE > command after errors). As you can see in the above output, the sense data > is all zero, which seems to be broken. At the moment it's not clear, wher= e > the problem exactly is: CAM, ATAPICAM or ATAPI. Since ATAng commit sense bytes are no longer automatically filled on error conditions. This very regression was worked around in recent growisofs (I did the testing for author). If you as kernel developer could try looking into it that would be great... --=20 Pav Lucistnik 42.7 percent of all statistics are made up on the spot. --=-d7mP70tQosXEgiKxuo17 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?= =?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?= =?ISO-8859-1?Q?_zpr=E1vy?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAF5SVntdYP8FOsoIRAg+gAKDJYyDRSttWSLuTofpp8BkIz7NUFgCdHy4i rs81ycLihzX9DVtVM8Np6nU= =i+EV -----END PGP SIGNATURE----- --=-d7mP70tQosXEgiKxuo17--