Date: Thu, 04 Mar 2010 19:14:21 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: gnome@FreeBSD.org Cc: Joe Marcus Clarke <marcus@FreeBSD.org> Subject: hald vs dvd+rw Message-ID: <4B8FEA6D.4050607@icyb.net.ua>
next in thread | raw e-mail | index | archive | help
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. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B8FEA6D.4050607>