hald vs dvd+rw
avg at icyb.net.ua
Mon Mar 8 08:36:22 UTC 2010
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.
More information about the freebsd-gnome