CD-ROM tray closes automatically after eject

Bug #356631 reported by FrenchNux on 2009-04-06
28
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
High
Andy Whitcroft
Jaunty
High
Andy Whitcroft
udev (Ubuntu)
High
Scott James Remnant (Canonical)
Jaunty
High
Martin Pitt

Bug Description

Disc drive : DVD-ROM Samsung SH-D163B

Problem:
When I try to eject a cd/dvd, Ubuntu jaunty inserts the cdrom right back in the cd/dvd drive

Steps to reproduce:
1) Either by pressing eject button on the device or using the "eject" command or using the eject icon in nautilus sidebar
2) The dvd is ejected successfully
3) The dvd is loaded back in right after being ejected. This happens after the message "eject: CD-ROM eject command succeeded" of "eject -v" command.

Pressing eject button when disc drive is empty = No issue

Brian Murray (brian-murray) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Could you add some more information to this bug report like the release of Ubuntu you are running and the specific package version of udev that you have installed? You can check via the 'apt-cache policy udev'. Thanks in advance.

affects: ubuntu → udev (Ubuntu)
Changed in udev (Ubuntu):
status: New → Incomplete
Brian Murray (brian-murray) wrote :

This also happens with my Jaunty system however it only happens with one of the drives in the system.

The persistent-storage rules file has changed a fair bit too from the patch that was included in Intrepid to resolve bug 283316.

Jaunty:

# 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"

Intrepid patch:

+# skip optical drives without media
+ENV{DEVTYPE}=="disk", KERNEL=="sr*", ENV{ID_CDROM_MEDIA_TRACK_COUNT}!="?*", GOTO="persistent_storage_end"

Brian Murray (brian-murray) wrote :

bug 353657 may be a duplicate of this

On Wed, 2009-04-08 at 01:11 +0000, Brian Murray wrote:

> bug 353657 may be a duplicate of this
>
Is there any evidence that udev is causing this?

Scott
--
Scott James Remnant
<email address hidden>

FrenchNux (christophe-pauc) wrote :

My release of Ubuntu is Jaunty beta 64bit

the package of udev is the default package of udev in Jaunty udev_140-2

FrenchNux (christophe-pauc) wrote :

I have 2 drives.
Issue only happens with one of the drives (DVD-ROM Samsung SH-D163B)

Brian Murray (brian-murray) wrote :

@Scott - How could I go about testing to determine whether or not it is in fact udev?

FrenchNux (christophe-pauc) wrote :

i disabled

# 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"

now it s ok

On Wed, 2009-04-08 at 16:29 +0000, FrenchNux wrote:

> i disabled
>
> # 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"
>
> now it s ok
>
Can you run "sudo udevadm monitor -e" and then eject your CD-ROM, you
should see output from that command which I'd like you to attach to the
bug report.

Scott
--
Scott James Remnant
<email address hidden>

Brian Murray (brian-murray) wrote :

This is after ejecting the problematic drive in my system with an audio CD inserted:

monitor will print the received events for:
UDEV the event which udev sends out after rule processing
UEVENT the kernel uevent

UEVENT[1239210231.132001] change /devices/pci0000:00/0000:00:1f.1/host4/target4:0:1/4:0:1:0 (scsi)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:1f.1/host4/target4:0:1/4:0:1:0
SUBSYSTEM=scsi
SDEV_MEDIA_CHANGE=1
DEVTYPE=scsi_device
DRIVER=sr
MODALIAS=scsi:t-0x05
SEQNUM=2158

UEVENT[1239210231.138724] change /devices/pci0000:00/0000:00:1f.1/host4/target4:0:1/4:0:1:0/block/sr1 (block)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:1f.1/host4/target4:0:1/4:0:1:0/block/sr1
SUBSYSTEM=block
DEVTYPE=disk
SEQNUM=2159
MAJOR=11
MINOR=1

UDEV [1239210231.138813] change /devices/pci0000:00/0000:00:1f.1/host4/target4:0:1/4:0:1:0 (scsi)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:1f.1/host4/target4:0:1/4:0:1:0
SUBSYSTEM=scsi
SDEV_MEDIA_CHANGE=1
DEVTYPE=scsi_device
DRIVER=sr
MODALIAS=scsi:t-0x05
SEQNUM=2158

UDEV [1239210234.112888] change /devices/pci0000:00/0000:00:1f.1/host4/target4:0:1/4:0:1:0/block/sr1 (block)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:1f.1/host4/target4:0:1/4:0:1:0/block/sr1
SUBSYSTEM=block
DEVTYPE=disk
SEQNUM=2159
ID_CDROM=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_MEDIA_STATE=blank
ID_CDROM_MEDIA_SESSION_NEXT=24832
ID_CDROM_MEDIA_SESSION_COUNT=16640
ID_CDROM_MEDIA_TRACK_COUNT=22272
ID_VENDOR=SONY
ID_VENDOR_ENC=SONY\x20\x20\x20\x20
ID_MODEL=CD-RW_CRX217E
ID_MODEL_ENC=CD-RW\x20\x20CRX217E\x20\x20
ID_REVISION=1DS2
ID_TYPE=cd
ID_BUS=scsi
ID_PATH=pci-0000:00:1f.1-scsi-0:0:1:0
GENERATED=1
DEVNAME=/dev/sr1
MAJOR=11
MINOR=1
DEVLINKS=/dev/block/11:1 /dev/scd1 /dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:1:0 /dev/cdrom1 /dev/cdrw1

FrenchNux (christophe-pauc) wrote :

after disabled # 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" :

monitor will print the received events for:
UDEV the event which udev sends out after rule processing
UEVENT the kernel uevent

UEVENT[1239213579.007656] change /devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0 (scsi)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0
SUBSYSTEM=scsi
SDEV_MEDIA_CHANGE=1
DEVTYPE=scsi_device
DRIVER=sr
MODALIAS=scsi:t-0x05
SEQNUM=1787

UEVENT[1239213579.008108] change /devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sr0 (block)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sr0
SUBSYSTEM=block
DEVTYPE=disk
SEQNUM=1788
MAJOR=11
MINOR=0

UDEV [1239213579.008290] change /devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0 (scsi)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0
SUBSYSTEM=scsi
SDEV_MEDIA_CHANGE=1
DEVTYPE=scsi_device
DRIVER=sr
MODALIAS=scsi:t-0x05
SEQNUM=1787

UDEV [1239213579.097023] change /devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sr0 (block)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sr0
SUBSYSTEM=block
DEVTYPE=disk
SEQNUM=1788
ID_CDROM=1
ID_CDROM_DVD=1
ID_CDROM_MEDIA_DVD=1
ID_CDROM_MEDIA_STATE=blank
ID_CDROM_MEDIA_SESSION_NEXT=55296
ID_CDROM_MEDIA_SESSION_COUNT=45312
ID_CDROM_MEDIA_TRACK_COUNT=20736
ID_VENDOR=TSSTcorp
ID_VENDOR_ENC=TSSTcorp
ID_MODEL=DVD-ROM_SH-D163B
ID_MODEL_ENC=DVD-ROM\x20SH-D163B
ID_REVISION=SB01
ID_TYPE=cd
ID_BUS=scsi
ID_PATH=pci-0000:00:1f.2-scsi-0:0:0:0
GENERATED=1
DEVNAME=/dev/sr0
MAJOR=11
MINOR=0
DEVLINKS=/dev/block/11:0 /dev/scd0 /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 /dev/cdrom1 /dev/dvd1

FrenchNux (christophe-pauc) wrote :

in attachement output with "probe filesystem ..." enabled :

# 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"

It seems that the kernel is returning bogus information about the number of tracks; given the randomishness of the numbers, perhaps this is uninitialised data.

Of the affected people, which are running i386 and which are running amd64?

affects: udev (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Incomplete → Triaged
Brian Murray (brian-murray) wrote :

I am running amd64.

FrenchNux (christophe-pauc) wrote :

amd64

FrenchNux (christophe-pauc) wrote :

With disc drives (DVD-ROM Samsung SH-D163B)
Empty cd-rw is unmounted.

FrenchNux (christophe-pauc) wrote :

Sorry i would like to say :
With my disc drives (DVD-ROM Samsung SH-D163B), Blank cdroms are unmounted and nothing in logs.

FrenchNux (christophe-pauc) wrote :

issue with blank cdrom is resolved but same issue with "eject" command

Same here: Two CD trays on my system, Jaunty pulls one of them right back in. I am running i386.

Martin Pitt (pitti) wrote :

Thanks everyone for attaching their udev logs. They confirm that after ejection, the track numbers are totally bogus:

  ID_CDROM_MEDIA_SESSION_NEXT=2894
  ID_CDROM_MEDIA_SESSION_COUNT=19194
  ID_CDROM_MEDIA_TRACK_COUNT=47323

and they are different for everyone.

This could be a kernel bug, but at least for an SRU I think it makes _much_ more sense to modify the rule to short-circuit the vol_id if "ID_CDROM_MEDIA_STATE=blank". In that case, it does not make sense to probe the session and track counts.

Could folks please confirm that inserting this line right before line 58 in /lib/udev/rules.d/60-persistent-storage.rules (i. e. right after the "# probe filesystem metadata of optical drives" comment) fixes the problem:

KERNEL=="sr*", ENV{ID_CDROM_MEDIA_STATE}=="blank", GOTO="persistent_storage_end"

Scott, WDYT?

Martin Pitt (pitti) wrote :

So the kernel bug is that the SCSI command to read CD information does not set those counts to 0 for blank media. I leave it open.

Instead of modifying the udev rules, ./extras/cdrom_id/cdrom_id.c, cd_media_info() could also zero those values for media_status=="blank", so that these numbers aren't printed in the first place.

Changed in linux (Ubuntu Jaunty):
importance: Undecided → Low
Martin Pitt (pitti) wrote :

Scott, want to commit this upstream? Thanks!

Changed in udev (Ubuntu Jaunty):
assignee: nobody → Scott James Remnant (scott)
importance: Undecided → High
status: New → Triaged

I can confirm that the insertion of the abovementioned line in the udev rules fixes this problem for me. Both drives stay open now.

On Mon, 2009-04-20 at 06:51 +0000, Martin Pitt wrote:

> So the kernel bug is that the SCSI command to read CD information does
> not set those counts to 0 for blank media. I leave it open.
>
> Instead of modifying the udev rules, ./extras/cdrom_id/cdrom_id.c,
> cd_media_info() could also zero those values for media_status=="blank",
> so that these numbers aren't printed in the first place.
>
Why is this better than fixing the kernel to set those counts to 0 for
blank media rather than returning initialised data?

Scott
--
Scott James Remnant
<email address hidden>

Martin Pitt (pitti) wrote :

Scott James Remnant [2009-04-20 10:47 -0000]:
> Why is this better than fixing the kernel to set those counts to 0 for
> blank media rather than returning initialised data?

An SRU which just adds one obvious udev rule is easier to review and
get through as SRU than a kernel update? Also, we have a fix in udev
for people out there right now, as opposed to a kernel fix which still
needs to be written. (Which is totally fine for Karmic)

FrenchNux (christophe-pauc) wrote :

I confirm that the insertion of the above mentioned line in the udev rules fixes this problem for me.
Both drives stay open now.

On Mon, 2009-04-20 at 11:34 +0000, Martin Pitt wrote:

> Scott James Remnant [2009-04-20 10:47 -0000]:
> > Why is this better than fixing the kernel to set those counts to 0 for
> > blank media rather than returning initialised data?
>
> An SRU which just adds one obvious udev rule is easier to review and
> get through as SRU than a kernel update? Also, we have a fix in udev
> for people out there right now, as opposed to a kernel fix which still
> needs to be written. (Which is totally fine for Karmic)
>
But the hack fix is not going to go upstream, and you specifically
suggested sending it upstream.

I'm personally nervous about making a change to the *standard* udev
rules that hasn't been confirmed with the kernel maintainer of that
subsystem, and tested properly.

Remember, these rules are used by all subscribing distros not just
Ubuntu. If there's a problem with them, or with the kernel, we should
have a much wider discussion net than just a bug that's fast-tracked
into an Ubuntu SRU.

Scott
--
Scott James Remnant
<email address hidden>

Martin Pitt (pitti) wrote :

Scott James Remnant [2009-04-20 14:38 -0000]:
> But the hack fix is not going to go upstream, and you specifically
> suggested sending it upstream.

I don't consider it a hack at all. It's a matter of style or opinion
whether you expect the track/session counts to have any meaning if
there is no CD in the drive at all. As I said, you could set the
values to zero in the kernel driver, or entirely ignore them in udev
if there's no CD. I don't see why the latter should be a hack; in
fact, in the "be liberal what you accept" programming practice it's
even the better solution, since it would allow newer udevs to run on
older kernels, too.

> I'm personally nervous about making a change to the *standard* udev
> rules that hasn't been confirmed with the kernel maintainer of that
> subsystem, and tested properly.

It was successfully tested above, and is really quite obvious, no?

> Remember, these rules are used by all subscribing distros not just
> Ubuntu.

That's the intent. I guess other distros are happy about this fix as
well.

> If there's a problem with them, or with the kernel, we should have a
> much wider discussion net than just a bug that's fast-tracked into
> an Ubuntu SRU.

I'd like to, but it's just about impossible to find an upstream bug
tracker for udev -- it's not on bz.kernel.org, not in copyright, not
linked in Launchpad, and google reveals nothing helpful either. Where
should I send it to?

Download full text (3.3 KiB)

On Mon, 2009-04-20 at 15:07 +0000, Martin Pitt wrote:

> Scott James Remnant [2009-04-20 14:38 -0000]:
> > But the hack fix is not going to go upstream, and you specifically
> > suggested sending it upstream.
>
> I don't consider it a hack at all. It's a matter of style or opinion
> whether you expect the track/session counts to have any meaning if
> there is no CD in the drive at all.
>
But does the attribute you point to only indicate that there is no CD in
the drive? The cursory examination I've done, along with the very name
of the setting, suggests that a CD _in_the_drive_ may be "blank".

> As I said, you could set the values to zero in the kernel driver
>
Pre-setting the values in the kernel to zero, before even checking,
instead of returning uninitialised data seems to be the "no brainer"
solution to me.

Any time I see uninitialised data, I see a bug.

> or entirely ignore them in udev if there's no CD. I don't see why the
> latter should be a hack;
>
Because I'm not convinced that the attribute you refer to _only_ means
"no CD".

The defined interface is that the ID_CDROM_MEDIA_TRACK_COUNT variable
will be *empty* for no CD. This clearly and unambiguously distinguishes
it from a CD with tracks (contains a non-zero numeric) and also from a
CD with no tracks (contains the number 0).

I think you need to prove that your suggested value has the same
semantics.

I do not think it does.

> infact, in the "be liberal what you accept" programming practice it's
> even the better solution, since it would allow newer udevs to run on
> older kernels, too.
>
Postel's Law absolutely does not apply here.

The kernel and udev obey *STRICT* interface requirements between each
other, as befits the fact that udev is fundamentally the userspace
marshaller of kernel information.

If udev were to begin to loosely parse kernel information, madness would
ensue.

Plus, simply and frankly, Postel's Law is intended to apply to the
interaction between a system that you control and a system that you do
not.

We control our own kernel.

We have the source to our own kernel.

If there is a bug in our kernel, we should not work around it, we should
fix the bug at its source - In The Kernel.

> > I'm personally nervous about making a change to the *standard* udev
> > rules that hasn't been confirmed with the kernel maintainer of that
> > subsystem, and tested properly.
>
> It was successfully tested above, and is really quite obvious, no?
>
The tests above do not, to my satisfaction, demonstrate that this will
not cause regressions.

> > Remember, these rules are used by all subscribing distros not just
> > Ubuntu.
>
> That's the intent. I guess other distros are happy about this fix as
> well.
>
Please don't guess.

> > If there's a problem with them, or with the kernel, we should have a
> > much wider discussion net than just a bug that's fast-tracked into
> > an Ubuntu SRU.
>
> I'd like to, but it's just about impossible to find an upstream bug
> tracker for udev -- it's not on bz.kernel.org, not in copyright, not
> linked in Launchpad, and google reveals nothing helpful either. Where
> should I send it to?
>
There is no bug tracker, just use the m...

Read more...

Martin Pitt (pitti) wrote :

Scott James Remnant [2009-04-21 1:41 -0000]:
> But does the attribute you point to only indicate that there is no CD in
> the drive? The cursory examination I've done, along with the very name
> of the setting, suggests that a CD _in_the_drive_ may be "blank".

*Nod* But then the CD still wouldn't have any tracks/sessions.

> The defined interface is that the ID_CDROM_MEDIA_TRACK_COUNT variable
> will be *empty* for no CD. This clearly and unambiguously distinguishes
> it from a CD with tracks (contains a non-zero numeric) and also from a
> CD with no tracks (contains the number 0).

I guess with "empty" you mean "absent" (cdrom_id will never print empty
variables, it's either a positive number or not printed at all). But
for an udev rule, empty and absent are pretty much the same, I
suppose. However, it means that with the current cdrom_id code you
cannot distinguish "no cd" from "blank cd" anyway.

> I think you need to prove that your suggested value has the same
> semantics.
>
> I do not think it does.

Within the currently exposed behaviour it does have the same semantics
(barring the problem of uninitialized track counts, which causes this
bug, of course). If you say that the currently exposed cdrom_id values
are wrong, then let's fix those instead, of course. Your call.

> Plus, simply and frankly, Postel's Law is intended to apply to the
> interaction between a system that you control and a system that you do
> not.

I absolutely disagree. Not the place to discuss this, though.

> If there is a bug in our kernel, we should not work around it, we should
> fix the bug at its source - In The Kernel.

*shrug* fine for me.

> There is no bug tracker, just use the mailing list - which is standard
> practice for everything Kernel-related INCLUDING THE KERNEL ITSELF:

Wrong, http://bugzilla.kernel.org/ tracks kernel bugs. It just doesn't
have a component for udev.

> The appropriate mailing list is <email address hidden>

OK, thanks (ugh!).

Martin Pitt (pitti) wrote :

Scott says we should fix this in the kernel, not udev. Bumping priority, and assigning to kernel team. Can we please fix this in an early SRU?

Changed in linux (Ubuntu Jaunty):
assignee: nobody → Canonical Kernel Team (canonical-kernel-team)
importance: Low → High

Hello udev developers,

https://launchpad.net/bugs/356631 reported that many people still have
the problem that after ejecting a CD, the CD-ROM tray automatically
closes again, causing the killing of fingers and CDs (or small pets :-) )

This problem came up a while ago already, and was solved with
introducing this into /lib/udev/rules.d/60-persistent-storage.rules:

  # 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"

However, this rule (and the corresponding code in cdrom_id [1]) relies
on the track/session counts being zero if there is no CD in the drive.
However, at least with kernel 2.6.28.8 the affected people get
something like

  ID_CDROM_MEDIA_STATE=blank
  ID_CDROM_MEDIA_SESSION_NEXT=2894
  ID_CDROM_MEDIA_SESSION_COUNT=19194
  ID_CDROM_MEDIA_TRACK_COUNT=47323

In other words, if ID_CDROM_MEDIA_STATE=blank, the session/track
counts are not reliable.

Arguably this could/should be fixed in the kernel, to fix these values
to 0 if there is no CD in the drive, or it is blank. However, I
wondered if the udev rules should be more robust in that regard, and
not even ask for the number of tracks if there is no/empty CD.
Affected people verified that adding this rule before the one from
above makes things work:

  KERNEL=="sr*", ENV{ID_CDROM_MEDIA_STATE}=="blank", GOTO="persistent_storage_end"

Thanks,

Martin

[1] if (cd_media_track_count > 0)
                printf("ID_CDROM_MEDIA_TRACK_COUNT=%d\n", cd_media_track_count);
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

On Tue, 2009-04-21 at 07:11 +0000, Martin Pitt wrote:

> Scott James Remnant [2009-04-21 1:41 -0000]:
> > But does the attribute you point to only indicate that there is no CD in
> > the drive? The cursory examination I've done, along with the very name
> > of the setting, suggests that a CD _in_the_drive_ may be "blank".
>
> *Nod* But then the CD still wouldn't have any tracks/sessions.
>
But then we'd still need to watch it for changes so should it gain
tracks/sessions, we'd update the udevdb as necessary.

Scott
--
Scott James Remnant
<email address hidden>

On Tue, Apr 21, 2009 at 09:25, Martin Pitt <email address hidden> wrote:
> However, this rule (and the corresponding code in cdrom_id [1]) relies
> on the track/session counts being zero if there is no CD in the drive.
> However, at least with kernel 2.6.28.8 the affected people get
> something like
>
>  ID_CDROM_MEDIA_STATE=blank
>  ID_CDROM_MEDIA_SESSION_NEXT=2894
>  ID_CDROM_MEDIA_SESSION_COUNT=19194
>  ID_CDROM_MEDIA_TRACK_COUNT=47323
>
> In other words, if ID_CDROM_MEDIA_STATE=blank, the session/track
> counts are not reliable.

Nice hardware! :)

> Arguably this could/should be fixed in the kernel, to fix these values
> to 0 if there is no CD in the drive, or it is blank. However, I
> wondered if the udev rules should be more robust in that regard, and
> not even ask for the number of tracks if there is no/empty CD.
> Affected people verified that adding this rule before the one from
> above makes things work:
>
>  KERNEL=="sr*", ENV{ID_CDROM_MEDIA_STATE}=="blank", GOTO="persistent_storage_end"

The problem is that there are other devices which report a blank media
for non-blank ones, so this rule would break these.

We changed it yesterday to use an ID_CDROM_MEDIA key:
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=f907449eee3f58fafafee0658e80578b1dbb2722

Would be good to know, if that works in the case you see the wrong values.

Thanks,
Kay

Martin Pitt (pitti) wrote :

I applied that upstream patch to a test package

 udev (141-1pitti1) jaunty; urgency=low
 .
   * Fix detection of CD media:
     - extras/cdrom_id/cdrom_id.c: Add a new key ID_CDROM_MEDIA=1 if there
       is a CD present.
     - rules/rules.d/60-persistent-storage.rules: Only start vol_id if
       ID_CDROM_MEDIA is set. This should fix the auto-closing of the tray.
       (LP: #356631)
     - Cherrypicked from upstream git f907449eee3f58fafafee0658e80578b1dbb2722

and uploaded it to my PPA: https://launchpad.net/~pitti/+archive/ppa

Could affected people please install this udev update and check whether it fixes their bug?

Andy Whitcroft (apw) wrote :

having had a look at cdrom_id it does appear at least to a cursory look that cdrom_id is interrogating the CD drive directly using raw SCSI commands over the sg interface. This implies at least that the drives in question are returnig the information you are producing directly. It is not 100% clear however that if the drive is empty that we should have got as far as we have through cdrom_id, ie. we might not have expected to have even requested this information:

        /* read drive and possibly current profile */
        if (cd_profiles(udev, fd) < 0)
                goto print;

        /* get session/track info */
        if (cd_media_toc(udev, fd) < 0)
                goto print;
* ->
        /* get writable media state */
        if (cd_media_info(udev, fd) < 0)
                goto print;

We might have expected the toc check to have failed and thus us to not have continued to get the media state. If we look at that code it also sends raw scsi commands. I suspect we are going to have to detect and work round this in userspace.

Andy Whitcroft (apw) wrote :

I am not sure that this upstream fix will help. It makes the udev scan effectively dependant on whether there is a current profile reported by the drive. The drive in the cases we have documented are reporting a profile, indeed if they were not we would not be attempting the TOC read and later. Notethe ID_CDROM_MEDIA_<type>=1 in each report below:

  ID_CDROM=1
  ID_CDROM_DVD=1
  ID_CDROM_MRW=1
  ID_CDROM_MRW_W=1
  ID_CDROM_MEDIA_CD=1
  ID_CDROM_MEDIA_STATE=blank
  ID_CDROM_MEDIA_SESSION_NEXT=2894
  ID_CDROM_MEDIA_SESSION_COUNT=19194
  ID_CDROM_MEDIA_TRACK_COUNT=47323

and:

  ID_CDROM=1
  ID_CDROM_DVD=1
  ID_CDROM_MEDIA_DVD=1
  ID_CDROM_MEDIA_STATE=blank
  ID_CDROM_MEDIA_SESSION_NEXT=55296
  ID_CDROM_MEDIA_SESSION_COUNT=45312
  ID_CDROM_MEDIA_TRACK_COUNT=20736

This is patently an error and one which appears to be coming direct from the drive. It is reporting itself still as containing something when it does not.

Before the upstream fix we could have elided the TRACK_COUNT when the device reported blank but that will not work following the upstream change.

Andy Whitcroft (apw) wrote :

The values which are miss-reported are coming direct from the drive via scsi-passthru on the SG device, the kernel is mearly passing this data back from the drive. It would appear that these drives are simply returning false information and if we wish to work around them we are likely to have to do so in userspace.

Changed in linux (Ubuntu Jaunty):
assignee: Canonical Kernel Team (canonical-kernel-team) → Andy Whitcroft (apw)
status: Triaged → Invalid
Stefan Bader (smb) wrote :

I agree with the above. As those are results of direct scsi commands and I have (at least one) a drive that works as expected. This invalidates the profile and returns "no profile" as soon as the cd is ejected. The question is whether there is enough data for userspace to make a sane decision. Somehow "blank" suggests the drive claims there is a media loaded while the track information is bogus. But that feels rather the drives firmware's fault.

FrenchNux (christophe-pauc) wrote :

> udev (141-1pitti1) jaunty; urgency=low
> .
> * Fix detection of CD media:
> - extras/cdrom_id/cdrom_id.c: Add a new key ID_CDROM_MEDIA=1 if there
> is a CD present.
> - rules/rules.d/60-persistent-storage.rules: Only start vol_id if
> ID_CDROM_MEDIA is set. This should fix the auto-closing of the tray.
> (LP: #356631)
> - Cherrypicked from upstream git f907449eee3f58fafafee0658e80578b1dbb2722
>
>and uploaded it to my PPA: https://launchpad.net/~pitti/+archive/ppa
>
>Could affected people please install this udev update and check whether it fixes their bug?

upstream fix don't fix bug !

FrenchNux (christophe-pauc) wrote :

I am not sure I understand everything.
is it possible to fix bug?

FrenchNux [2009-04-22 7:45 -0000]:
> upstream fix don't fix bug !

Can you please copy&paste the output of

  sudo udevadm monitor --udev --environment

with the PPA package installed, and when you open the drive? (and it
auto-closes again). Thanks!

FrenchNux (christophe-pauc) wrote :

monitor will print the received events for:
UDEV - the event which udev sends out after rule processing

UDEV [1240402975.415441] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0
SUBSYSTEM=scsi
SDEV_MEDIA_CHANGE=1
DEVTYPE=scsi_device
DRIVER=sr
MODALIAS=scsi:t-0x05
SEQNUM=1716

UDEV [1240402978.959576] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr1 (block)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr1
SUBSYSTEM=block
DEVTYPE=disk
SEQNUM=1717
ID_CDROM=1
ID_CDROM_DVD=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_DVD=1
ID_CDROM_MEDIA_STATE=blank
ID_CDROM_MEDIA_SESSION_NEXT=46336
ID_CDROM_MEDIA_SESSION_COUNT=33024
ID_CDROM_MEDIA_TRACK_COUNT=58368
ID_VENDOR=TSSTcorp
ID_VENDOR_ENC=TSSTcorp
ID_MODEL=DVD-ROM_SH-D163B
ID_MODEL_ENC=DVD-ROM\x20SH-D163B
ID_REVISION=SB01
ID_TYPE=cd
ID_BUS=scsi
ID_PATH=pci-0000:00:1f.2-scsi-1:0:0:0
GENERATED=1
DEVNAME=/dev/sr1
MAJOR=11
MINOR=1
DEVLINKS=/dev/block/11:1 /dev/scd1 /dev/disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0 /dev/cdrom /dev/dvd

UDEV [1240402986.667051] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0
SUBSYSTEM=scsi
SDEV_MEDIA_CHANGE=1
DEVTYPE=scsi_device
DRIVER=sr
MODALIAS=scsi:t-0x05
SEQNUM=1718

UDEV [1240402991.667767] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr1 (block)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr1
SUBSYSTEM=block
DEVTYPE=disk
SEQNUM=1719
ID_CDROM=1
ID_CDROM_DVD=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_DVD=1
ID_CDROM_MEDIA_STATE=complete
ID_CDROM_MEDIA_SESSION_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
ID_VENDOR=TSSTcorp
ID_VENDOR_ENC=TSSTcorp
ID_MODEL=DVD-ROM_SH-D163B
ID_MODEL_ENC=DVD-ROM\x20SH-D163B
ID_REVISION=SB01
ID_TYPE=cd
ID_BUS=scsi
ID_PATH=pci-0000:00:1f.2-scsi-1:0:0:0
ID_FS_USAGE=filesystem
ID_FS_TYPE=udf
ID_FS_LABEL=Casino_Royale
ID_FS_LABEL_ENC=Casino\x20Royale
GENERATED=1
FSTAB_NAME=/dev/scd1
FSTAB_DIR=/media/cdrom1
FSTAB_TYPE=udf,iso9660
FSTAB_OPTS=user,noauto,exec,utf8
FSTAB_FREQ=0
FSTAB_PASSNO=0
DEVNAME=/dev/sr1
MAJOR=11
MINOR=1
DEVLINKS=/dev/block/11:1 /dev/scd1 /dev/disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0 /dev/disk/by-label/Casino\x20Royale /dev/cdrom /dev/dvd

Hello Kay,

Kay Sievers [2009-04-21 10:52 +0200]:
> Nice hardware! :)

If only it was real!

> The problem is that there are other devices which report a blank media
> for non-blank ones, so this rule would break these.

Ah, understood. Yay buggy CD-ROM firmware.

> We changed it yesterday to use an ID_CDROM_MEDIA key:
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=f907449eee3f58fafafee0658e80578b1dbb2722
>
> Would be good to know, if that works in the case you see the wrong values.

I got a reply from two testers, unfortunately it doesn't see to help
at all. With the patch, he gets this on eject:

UDEV [1240402978.959576] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr1 (block)
ACTION=change
SUBSYSTEM=block
DEVTYPE=disk
ID_CDROM=1
ID_CDROM_DVD=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_DVD=1
ID_CDROM_MEDIA_STATE=blank
ID_CDROM_MEDIA_SESSION_NEXT=46336
ID_CDROM_MEDIA_SESSION_COUNT=33024
ID_CDROM_MEDIA_TRACK_COUNT=58368
[...]

(full log in the Launchpad bug)

Thanks,

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

On Wed, Apr 22, 2009 at 15:34, Martin Pitt <email address hidden> wrote:

>> We changed it yesterday to use an ID_CDROM_MEDIA key:
>>   http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=f907449eee3f58fafafee0658e80578b1dbb2722
>>
>> Would be good to know, if that works in the case you see the wrong values.
>
> I got a reply from two testers, unfortunately it doesn't see to help
> at all. With the patch, he gets this on eject:
>
> UDEV  [1240402978.959576] change   /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr1 (block)
> ACTION=change
> SUBSYSTEM=block
> DEVTYPE=disk
> ID_CDROM=1
> ID_CDROM_DVD=1
> ID_CDROM_MEDIA=1

Hmm, so we need to find a more reliable way to check for a media. We
probably need to ask the kernel with some cdrom ioctl() instead of
just talking SG_IO here. In the hope, the ioctls do more checks, to
support broken hardware like this.

Kay

Hello Kay,

Kay Sievers [2009-04-23 0:16 +0200]:
> Hmm, so we need to find a more reliable way to check for a media. We
> probably need to ask the kernel with some cdrom ioctl() instead of
> just talking SG_IO here.

Indeed I was wondering about that; do you plan to use the
CDROM_DISC_STATUS ioctl? I found that quite reliable, and it would
keep the fiddly bits in one place in the kernel.

Thanks!

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

On Thu, Apr 23, 2009 at 09:35, Martin Pitt <email address hidden> wrote:
> Kay Sievers [2009-04-23  0:16 +0200]:
>> Hmm, so we need to find a more reliable way to check for a media. We
>> probably need to ask the kernel with some cdrom ioctl() instead of
>> just talking SG_IO here.
>
> Indeed I was wondering about that; do you plan to use the
> CDROM_DISC_STATUS ioctl? I found that quite reliable, and it would
> keep the fiddly bits in one place in the kernel.

Ok, let's try:
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=d6f0b22d574c6a5e5f3430be3fc619d4b2f46cd5

to check the DRIVE, if we should look for a media at all. If that's
still not enough, we will need to try the DISC ioctl.

Thanks a lot,
Kay

Martin Pitt (pitti) wrote :

I applied the second upstream patch to a new test package

udev (141-1pitti2) jaunty; urgency=low

  * Fix detection of CD media:
    - extras/cdrom_id/cdrom_id.c: Add a new key ID_CDROM_MEDIA=1 if there
      is a CD present. Also, skip media tests if CDROM_DRIVE_STATUS !=
      CDS_DISC_OK.
    - rules/rules.d/60-persistent-storage.rules: Only start vol_id if
      ID_CDROM_MEDIA is set. This should fix the auto-closing of the tray.
      (LP: #356631)
    - Cherrypicked from upstream git f907449ee and d6f0b22d5.

 -- Martin Pitt <email address hidden> Tue, 21 Apr 2009 11:16:56 +0200

and uploaded it to my PPA: https://launchpad.net/~pitti/+archive/ppa

Could affected people please install this udev update and check whether it fixes their bug? If it still does not work, please include the output of

  sudo udevadm monitor --udev --environment

again. Thank you!

udev (141-1pitti2) jaunty
does the trick for me.

FrenchNux (christophe-pauc) wrote :

it s ok !!! bug fixed

Martin Pitt (pitti) wrote :

Thanks everyone for testing! I uploaded this to the jaunty-proposed queue now, waiting for Steve or Colin to process:

udev (141-1.1) jaunty-proposed; urgency=low

  * Fix detection of CD media:
    - extras/cdrom_id/cdrom_id.c: Add a new key ID_CDROM_MEDIA=1 if there
      is a CD present. Also, skip media tests if CDROM_DRIVE_STATUS !=
      CDS_DISC_OK.
    - rules/rules.d/60-persistent-storage.rules: Only start vol_id if
      ID_CDROM_MEDIA is set. This should fix the auto-closing of the tray.
      (LP: #356631)
    - Cherrypicked from upstream git f907449ee and d6f0b22d5.

 -- Martin Pitt <email address hidden> Tue, 21 Apr 2009 11:16:56 +0200

Changed in udev (Ubuntu Jaunty):
assignee: Scott James Remnant (scott) → Martin Pitt (pitti)
status: Triaged → Fix Committed
Martin Pitt (pitti) wrote :

Fixes are committed upstream, so they'll land in karmic with the next upstream git pull or release.

Changed in udev (Ubuntu):
status: Triaged → Fix Committed
Steve Langasek (vorlon) wrote :

Accepted into jaunty-proposed, the package will build now and be available in a few hours.Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags: added: verification-needed
Brian Murray (brian-murray) wrote :

Using udev version 141-1.1 I confirm that the disc drive will stay open now and not close again right away as it did with the previous version.

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package udev - 141-1.1

---------------
udev (141-1.1) jaunty-proposed; urgency=low

  * Fix detection of CD media:
    - extras/cdrom_id/cdrom_id.c: Add a new key ID_CDROM_MEDIA=1 if there
      is a CD present. Also, skip media tests if CDROM_DRIVE_STATUS !=
      CDS_DISC_OK.
    - rules/rules.d/60-persistent-storage.rules: Only start vol_id if
      ID_CDROM_MEDIA is set. This should fix the auto-closing of the tray.
      (LP: #356631)
    - Cherrypicked from upstream git f907449ee and d6f0b22d5.

 -- Martin Pitt <email address hidden> Tue, 21 Apr 2009 11:16:56 +0200

Changed in udev (Ubuntu Jaunty):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

Copied jaunty-proposed to karmic.

Changed in udev (Ubuntu):
status: Fix Committed → Fix Released
Changed in udev (Ubuntu Jaunty):
status: Fix Released → New
Changed in udev (Ubuntu Jaunty):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions