Skip to contentSkip to conversation

CD-ROM tray closes automatically after eject due to random

DISCUSSION Martin Pitt 2 participants 7 messages Apr 21, 2009 – Apr 23, 2009

lore
Share & tools
lore

Martin Pitt

author
#0 lore raw

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);
Signature · 2 lines
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
#1 lore raw
Quoted 5 lines · Martin Pitt

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

Quoted 7 lines

 ID_CDROM_MEDIA_STATE=blank
 ID_CDROM_MEDIA_SESSION_NEXT(94
 ID_CDROM_MEDIA_SESSION_COUNT194
 ID_CDROM_MEDIA_TRACK_COUNTG323

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

Nice hardware! :)

Quoted 8 lines

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ù07449eee3f58fafafee0658e80578b1dbb2722

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

Thanks,
Kay

author
#2 lore raw
In reply to Martin Pitt

Hallo Kay,

Kay Sievers [2009-04-21 10:52 +0200]:

Quoted 4 lines

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

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

Thanks! I'll build a test package for these folks to try, will report back.

Martin

Signature · 2 lines
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
author
#3 lore raw
In reply to Martin Pitt

Hello Kay,

Kay Sievers [2009-04-21 10:52 +0200]:

Quoted 1 line

Nice hardware! :)

If only it was real!

Quoted 2 lines

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.

Quoted 4 lines

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

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_NEXTF336
ID_CDROM_MEDIA_SESSION_COUNT3024
ID_CDROM_MEDIA_TRACK_COUNTX368
[...]

(full log in the Launchpad bug)

Thanks,

Martin

Signature · 2 lines
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
#4 lore raw
In reply to Martin Pitt
Quoted 8 lines · Martin Pitt
Quoted 4 lines

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

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:

Quoted 7 lines

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

author
#5 lore raw
In reply to Martin Pitt

Hello Kay,

Kay Sievers [2009-04-23 0:16 +0200]:

Quoted 3 lines

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

Signature · 2 lines
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
#6 lore raw
In reply to Martin Pitt
Quoted 8 lines · Martin Pitt

Kay Sievers [2009-04-23  0:16 +0200]:

Quoted 3 lines

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�f0b22d574c6a5e5f3430be3fc619d4b2f46cd5

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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html