From owner-freebsd-gnome@FreeBSD.ORG Mon Mar 8 08:36:22 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 BD38C106564A for ; Mon, 8 Mar 2010 08:36:22 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0C2AF8FC1E for ; Mon, 8 Mar 2010 08:36:21 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA29609; Mon, 08 Mar 2010 10:36:17 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NoYRk-000075-O4; Mon, 08 Mar 2010 10:36:16 +0200 Message-ID: <4B94B6FF.2040303@icyb.net.ua> Date: Mon, 08 Mar 2010 10:36:15 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: Joe Marcus Clarke References: <4B8FEA6D.4050607@icyb.net.ua> <1268011256.96436.24.camel@shumai.marcuscom.com> In-Reply-To: <1268011256.96436.24.camel@shumai.marcuscom.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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 08:36:22 -0000 on 08/03/2010 03:20 Joe Marcus Clarke said the following: > 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±RW >> media. I specifically mean the case when media already contains CD9660 or 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) >> >> At the worst, it causes confusion for the burning program. >> This happens with recent versions of 9-CURRENT and 8-STABLE, when using atacam and >> ahci driver for programs like growisofs from dvd+rw-tools and cdrecord from >> cdrecord-devel. And, of course, for frontends that use those as backends. >> >> 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? No, I haven't. Thank you for the information! OTOH, I tried burning with k3b (from k3b-kde4), which is supposed to be smart about hal, but got exactly the same issue. -- Andriy Gapon