From owner-freebsd-gnome@FreeBSD.ORG Mon Mar 8 01:20:39 2010 Return-Path: Delivered-To: gnome@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F04A9106564A for ; Mon, 8 Mar 2010 01:20:39 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 897368FC0A for ; Mon, 8 Mar 2010 01:20:39 +0000 (UTC) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.4/8.14.4) with ESMTP id o281LK4Q088954; Sun, 7 Mar 2010 20:21:20 -0500 (EST) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Andriy Gapon In-Reply-To: <4B8FEA6D.4050607@icyb.net.ua> References: <4B8FEA6D.4050607@icyb.net.ua> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-FeGk97LZfEg2kLedQeaG" Organization: MarcusCom, Inc. Date: Sun, 07 Mar 2010 20:20:56 -0500 Message-ID: <1268011256.96436.24.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,HELO_NO_DOMAIN autolearn=no version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on creme-brulee.marcuscom.com Cc: gnome@freebsd.org Subject: Re: hald vs dvd+rw X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 01:20:40 -0000 --=-FeGk97LZfEg2kLedQeaG Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable On Thu, 2010-03-04 at 19:14 +0200, Andriy Gapon wrote: > It seems that hald behavior might be causing some issues with re-writing = DVD=B1RW > media. I specifically mean the case when media already contains CD9660 o= r UDF > filesystem and is being re-written with new data. > It seems that when hald notices old volume going away, it attempts to re-= taste the > media while a burning program, e.g. growisofs, may be writing data to the= media. > At the very least it produces messages in system log like the following: > kernel: (cd0:ahcich5:0:0:0): READ TOC/PMA/ATIP. CDB: 43 0 0 0 0 0 0 0 4 0 > kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition > kernel: (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit = not > ready, long write in progress) >=20 > At the worst, it causes confusion for the burning program. > This happens with recent versions of 9-CURRENT and 8-STABLE, when using a= tacam and > ahci driver for programs like growisofs from dvd+rw-tools and cdrecord fr= om > cdrecord-devel. And, of course, for frontends that use those as backends= . >=20 > I am not sure how to resolve this properly. > Perhaps, hald could have a special treatment for 'Logical unit not ready,= long > write in progress' sense from TEST UNIT READY command. Have you followed the steps at http://www.freebsd.org/gnome/docs/halfaq.html#q6 to lock the device in hal, and prevent access while burning your media? Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-FeGk97LZfEg2kLedQeaG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAkuUUPYACgkQb2iPiv4Uz4fvEACgmk2B5ryYmrMrReJkq3yRQ34J 13wAnjadkrkU421a4r7hKM1+01a7RnY9 =pcmC -----END PGP SIGNATURE----- --=-FeGk97LZfEg2kLedQeaG--