From owner-freebsd-gnome@FreeBSD.ORG Tue Mar 9 16:50:40 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 F2817106566B for ; Tue, 9 Mar 2010 16:50:40 +0000 (UTC) (envelope-from marcus@freebsd.org) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by mx1.freebsd.org (Postfix) with ESMTP id 979178FC0A for ; Tue, 9 Mar 2010 16:50:40 +0000 (UTC) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o29GocVv023880; Tue, 9 Mar 2010 11:50:38 -0500 (EST) Received: from dhcp-64-102-220-55.cisco.com (dhcp-64-102-220-55.cisco.com [64.102.220.55]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o29Gobtd002271; Tue, 9 Mar 2010 11:50:37 -0500 (EST) Message-ID: <4B967C5D.8030405@freebsd.org> Date: Tue, 09 Mar 2010 11:50:37 -0500 From: Joe Marcus Clarke Organization: FreeBSD, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Andriy Gapon References: <4B8FEA6D.4050607@icyb.net.ua> <1268011256.96436.24.camel@shumai.marcuscom.com> <4B94B6FF.2040303@icyb.net.ua> In-Reply-To: <4B94B6FF.2040303@icyb.net.ua> 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: Tue, 09 Mar 2010 16:50:41 -0000 On 3/8/10 3:36 AM, Andriy Gapon wrote: > 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. > > Yeah, it should be hal-aware, but I'm not sure if it actually locks the device. Using hal-lock explicitly will rule out such problems. The media polling add-on is lock-aware, and should stop polling while the device is locked. However, if GEOM changes under the covers, then that could trigger a re-poll. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome