hald vs dvd+rw

[Joe Marcus Clarke]

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?

Joe

-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20100308/0757fa10/attachment.pgp