On Tue, Jan 20, 2009 at 5:22 PM, Marco d'Itri <m...@linux.it> wrote:
> On Jan 20, Christopher Montgomery <xiphm...@gmail.com> wrote:
>
> The upstream rules files currently have this rule:
>
>> # probe filesystem metadata of disks
>> KERNEL!="sr*", IMPORT{program}="vol_id --export $tempnode"
>
> I am not confortable adding this one while we are so much close to the
> release, unless you are willing to provide a deep analisys of how and
> why it solves this problem and exactly in which ways it is different
> (i.e. it exercises different code paths) from the current situation:
>
>> # probe filesystem metadata of optical drives which have a media inserted
>> KERNEL=="sr*", ENV{ID_CDROM_MEDIA_TRACK_COUNT}=="?*",
>> IMPORT{program}="vol_id \
>> --export --skip-raid
>> --offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET} \
>> $tempnode"
I included the rule verbatim from the upstream sources. You're right
to notice the surrounding context is slightly different, such that two
of the qualifications are redundant but harmless (I wanted to keep the
similarity to upstream to ease any patching moving forward). The
intended effect is to still run vol_id on the sr* devices, but to
prevent probing raid signatures that will fall off the end of a
session and render the device probe unusable due to the unintended
consequences of media errors.
Without skipping the RAID signature checks, udev startup will reliably
timeout or fail on a decent subset of DVD/CDROM drives that report a
READ_CAPACITY that includes any partially-burned trailing sectors (eg,
Pioneer 216D). This affects all burned media on such a drive;
commercially pressed discs are usually unaffected. If udev does get
through the timeout, media changes may fail due to repeated errors. At
a minimum, such drives will cause substatntial delays (30s+) during
boot and upon disc change. At worst, the drive/controller is kicked.
This makes such a drive practically unusable.
I'm happy to provide as detailed an analysis as necessary. I am
versed in both the udev and kernel driver code relevant to the
situation, feel free to ask any questions, hopefully I have an anwer
(or can get it :-)
Monty
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
