freebsd-gnome Digest, Vol 359, Issue 3
freebsd-gn...@freebsd.org
freebs...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-gnome
or, via email, send a message with subject or body 'help' to
freebsd-gn...@freebsd.org
You can reach the person managing the list at
freebsd-g...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-gnome digest..."
Today's Topics:
1. Re: hald vs dvd+rw (Joe Marcus Clarke)
2. Re: hald vs dvd+rw (Andriy Gapon)
----------------------------------------------------------------------
Message: 1
Date: Tue, 09 Mar 2010 11:50:37 -0500
From: Joe Marcus Clarke <mar...@freebsd.org>
Subject: Re: hald vs dvd+rw
To: Andriy Gapon <a...@icyb.net.ua>
Cc: gn...@freebsd.org
Message-ID: <4B967C5D...@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
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 :: gn...@FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
------------------------------
Message: 2
Date: Wed, 10 Mar 2010 00:15:52 +0200
From: Andriy Gapon <a...@icyb.net.ua>
Subject: Re: hald vs dvd+rw
To: Joe Marcus Clarke <mar...@freebsd.org>
Cc: gn...@freebsd.org
Message-ID: <4B96C898...@icyb.net.ua>
Content-Type: text/plain; charset=ISO-8859-1
on 09/03/2010 18:50 Joe Marcus Clarke said the following:
> 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.
Got it, thanks!
--
Andriy Gapon
------------------------------
End of freebsd-gnome Digest, Vol 359, Issue 3
*********************************************