Bugzilla – Bug 157546
CD/DVD drive is locked after inserting media
Last modified: 2007-01-17 17:55:45 UTC
Freshly installed SL10.1b7 (no update) from CD set. KDE, C/C++ development, advanced user as selection. KDE is running. When I insert a CD, it is automatically mounted. However, one cannot unload the disk by pressing the drive unload button, only by using the eject menu entry of the disk icon. hdparm -L0 /dev/hdc does not work on this system, so this *might* be a system specific problem. I'm not sure about the mechanism behind disk automounting. Machine is gkar, ssh is open, CD 5 is in the drive.
This needs to be in the release notes: SUSE 10.1 uses a new mounting mechanism replacing the submount system we used earlier. As such media isn't unmounted automatically, but on hardware request. Some hardware (most notably older CD drives, but also some newer ones with broken firmware) won't send this signal though. You need to press the right mouse button in "My Computer" on the media to eject. Matthias: Compile ~axboe/cd_poll.c and test your CD drive (as root) with it.
OK, Karl, please add.
How is it handled on Gnome? "Click on the device icon and select 'Eject'."?
Submitted to /work . I guess, since the button is available on the Gnome desktop there is no need to mention it explicitly.
It works basically the same on GNOME as KDE. The hardware eject button is handled as well as right click eject on the desktop icon or in my computer. As noted some older CD drives may have issues with the hardware eject button.
thanks for the additional info!
The drive we are talking about is a LTN486S according to /proc/ide. Sorry, don't know more details. (In reply to comment #1) > Matthias: Compile ~axboe/cd_poll.c and test your CD drive (as root) with it. It does not print out any events when I press the unload button on the drive. When I interrupt it, it unlocks the tray (no error). Afterwards I can eject the drive using the unload button. Now if I restart the program before hitting the unload button, I get a Status: door closed, media not loaded event: media removal Status: door open, media not loaded upon pressing the unload button. This should be enough to trigger the unmount. In fact, it does. The medium is no longer mounted after unload. As I said before, I do *not* get this event on the first start of the program, that is with the door locked. This is kinda strange, as "hdparm -L0" bails out with "HDIO_DRIVE_CMD(doorlock) failed: Input/output error" on this drive. I still find this quite anoying, and I guess many of our customers will feel so as well. What stands against unlocking the drive on the very beginning? Its read-only anyway...
Reopening in order to get an answer for the question why the drive cannot be kept in an unlocked state, which would help for this kind of drive. Setting to major (not critical) because the CD *can* be umounted (if the user knows what to do).
Can reproduce with beta8. It also affects YaST (see bug #157537), when installing new software. You have to open "My Computer" and choose eject for next CD. My drive is a TOSHIBA DVD-ROM SD-M1612.
daniel, does hal do the locking?
I wonder if this is necessary in any way to lock read only media. And I always thought the kernel locks on mount - no hal necessary.
The kernel always locks the tray, read-only or read-write. You can disable that feature by using the 'lockdoor' module parameter, however that's not good enough of course. We could turn that into a 'only lock for rw open', if we are sure that iso9660/udf/hfs/whatever-is-used-on-a-dvd/cd handle media revoke in a suitable fashion.
*** Bug 159157 has been marked as a duplicate of this bug. ***
As I understood Jens this is the normal behavior we've always had. So I see not what I/we can do here. I would close the bug.
Its not what we had so far, because previously one was able to eject an inserted medium, because subfs unmounted. the new stuff doesn't do that anymore, so there is no way to get your media back.
That points the finger at someone opening the CDROM device with O_NONBLOCK set. I would check for that. Another problem that has reared it's ugly head every now and then is if you open the device O_NONBLOCK (tray remains unlocked), someone opens it blocking (tray is locked), the blocked owner closes, and tray remains locked because it has a non-zero usage count.
I have no idea what's going on behind the scenes. The only thing that reminds me that your observation should not have anything to do with this issue is that only when running your cd_poll the tray is *not* locked. I don't think cd_poll mounts the medium, so this is still done by the system, so there's no difference here. (In reply to comment #12) > The kernel always locks the tray, read-only or read-write. You can disable that > feature by using the 'lockdoor' module parameter, however that's not good > enough of course. Is this documented somewhere? Certainly not in linux/Documentation/kernel-parameters.txt...
Jens: the solution before was subfs, which iirc unmounted as soon as it was "done", so you didn't have the tray permanently locked, like it is now. and how do you use O_NONBLOCK? do you mean we have to patch each and every userland application to open files with O_NONBLOCK so that the kernel lock the drive on a read-only mount?
I fear we cannot do anything - if that's possible at all - for CODE10 here. Let's assign this to Olaf as architect for the base system if he has a clever idea - and if not let him close it.
*** Bug 157537 has been marked as a duplicate of this bug. ***
Closed due to inactivity. If this is still an issue, please reopen.