Hi,
i am developer of libburn and CD/DVD/BD burn program xorriso.
It seems urgent that i coordinate the activities of libburn with the
activities of udev.
What is the recommended way for a library resp. a console program
to tell udev, that the drive and the media will undergo arbitrary
changes and should not be accessed during that time ?
The particular problem case:
On an installation of Debian GNU/Linux 6.0.2 amd64, /dev/dvdrw vanishes
if libburn loads the tray. It comes back only if some other program run
uses the /dev/sr device file to which the link should point.
The effect is not always reproducible. Typically it happens with DVD+RW
media, not with CD-RW or empty tray. It seems related to the habit
of xorriso to inspect the media for existing ISO 9660 filesystems.
If the system is in the mood for it, then it already happens with
xorriso -outdev /dev/sr0
Less frequently i can reproduce it with wodim
wodim dev=/dev/sr0 -toc
Quite reliably it happens with a xorriso burn run on DVD+RW (e.g. /usr/bin
to DVD+RW):
xorriso -outdev /dev/sr0 -blank as_needed -add /usr/bin --
There are two drives attached to the system:
a SATA DVD burner SH-S223B
a PATA DVD-ROM SH-D162C
Mostly the burner is sr0, but on some days it is sr1. So udev's links
are needed to configure persistent addresses in backup programs.
-----------------------------------------------------------------------------
/etc/udev/rules.d/70-persistent-cd.rules
-----------------------------------------------------------------------------
# This file was automatically generated by the /lib/udev/write_cd_rules
# program, run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and set the $GENERATED variable.
# CDDVDW_SH-S223B (pci-0000:00:11.0-scsi-2:0:0:0)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:11.0-scsi-2:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:11.0-scsi-2:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:11.0-scsi-2:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:11.0-scsi-2:0:0:0", SYMLINK+="dvdrw", ENV{GENERATED}="1"
# DVD-ROM_SH-D162C (pci-0000:00:14.1-scsi-0:0:0:0)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:14.1-scsi-0:0:0:0", SYMLINK+="cdrom1", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:14.1-scsi-0:0:0:0", SYMLINK+="dvd1", ENV{GENERATED}="1"
-----------------------------------------------------------------------------
After booting, i executed
udevadm control --log-priority=debug
Then i put a DVD+RW into the tray, leave it open and execute:
xorriso -outdev /dev/sr0
xorriso loads the tray by SCSI command START/STOP UNIT. A few seconds
later /dev/dvdrw is gone.
The vanishing link is accompanied by these messages in /var/log/daemon.log :
------------------------------------------------------------------
Sep 9 22:00:41 debian2 udevd[435]: seq 1274 queued, 'change' 'scsi'
[...]
Sep 9 22:00:41 debian2 udevd-work[21697]: 'cdrom_id --export /dev/sr0' started
Sep 9 22:00:41 debian2 cdrom_id[21698]: custom logging function 0x7f17909c9010 registered
Sep 9 22:00:47 debian2 cdrom_id[21698]: unable to open '/dev/sr0'
Sep 9 22:00:47 debian2 udevd-work[21697]: '/lib/udev/cdrom_id' (stderr) 'unable to open '/dev/sr0''
Sep 9 22:00:47 debian2 udevd-work[21697]: 'cdrom_id --export /dev/sr0' returned with exitcode 1
[...]
Sep 9 22:00:48 debian2 udevd-work[21697]: update old name, '/dev/dvdrw' no longer belonging to '/devices/pci0000:00/0000:00:11.0/host2/target2:0:0/2:0:0:0/block/sr0'
Sep 9 22:00:48 debian2 udevd-work[21697]: no reference left, remove '/dev/dvdrw'
[... no attempt to create a new /dev/dvdrw ...]
Sep 9 22:00:48 debian2 udevd[435]: seq 1275 done with 0
------------------------------------------------------------------
It looks as if xorriso's activities block the drive while udev is trying
to get access to it in the time between 22:00:41 and 22:00:47.
The subsequent repair happens by accessing the drive again with another
xorriso -outdev /dev/sr0
This time the tray is closed.
------------------------------------------------------------------
Sep 9 22:01:06 debian2 udevd[435]: seq 1276 queued, 'change' 'scsi'
[...]
Sep 9 22:01:06 debian2 udevd-work[21697]: 'cdrom_id --export /dev/sr0' started
Sep 9 22:01:06 debian2 cdrom_id[22669]: custom logging function 0x7f3e72142010 registered
Sep 9 22:01:10 debian2 cdrom_id[22669]: probing: '/dev/sr0'
Sep 9 22:01:10 debian2 cdrom_id[22669]: INQUIRY: [TSSTcorp][CDDVDW SH-S223B ][SB02]
[... many other SCSI inquiry command results ...]
Sep 9 22:01:16 debian2 udevd-work[21697]: LINK 'dvdrw' /etc/udev/rules.d/70-persistent-cd.rules:11
[...]
Sep 9 22:01:16 debian2 udevd-work[21697]: creating link '/dev/dvdrw' to '/dev/sr0'
Sep 9 22:01:16 debian2 udevd-work[21697]: creating symlink '/dev/dvdrw' to 'sr0'
[...]
Sep 9 22:01:16 debian2 udevd[435]: seq 1277 done with 0
------------------------------------------------------------------
wodim seems a bit less problematic, because it does not perform READ
commands. xorriso does this to learn about possible ISO 9660 fileystems.
I assume they add a few extra seconds to the drive occupation.
I tried to load the tray by
ioctl(fd, CDROMCLOSETRAY, 0);
before performing SCSI command START/STOP UNIT. No improvement seen.
Have a nice day :)
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
