Bug 138964
| Summary: | eject unable to eject cd/dvd | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | James Bennett <jbennett> | ||||
| Component: | kernel | Assignee: | Dave Jones <davej> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3 | CC: | amk, pfrields, ralston, sandip | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2005-07-15 22:41:51 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
if pressing eject button on the drive itself fails and no file on device is open, it seems a bug in kernel driver. unless something still has a reference count on that cd. nautilus (or some other desktop component) seems to automount things. do you have an icon on your desktop ? does the cdrom seem to be mounted if you type 'mount' in a shell ? do you get any messages in dmesg after a failed 'eject' ? Dave, the CD isn't mounted; I've disabled all of the automount/autorun stuff, and when I started seeing this problem I double-checked just to be sure. Between that and `lsof` I'm pretty sure nothing's using the device. Regardless of the user `eject` is running as, the following pops up in the kernel message log: Nov 14 02:26:04 localhost kernel: program eject is using a deprecated SCSI ioctl, please convert it to SG_IO But as root the disc is actually ejected. I'm getting the exact same behavior on my system. I have a brand new NEC 3500 DVD burner. This behavior did not occur in Fedora Core 2. The only eject command method that works is SCSI. CD-ROM and others do not. Hitting either the button on the drive or the button in gnome-cd doesn't even interrupt audio CD play. I believe I have been seeing the same problem: CDs with both audio and
data tracks behave very strangely. When I just mount (either
automatically (gnome-volume-manager/hald) or just using the command
'mount /dev/cdrom /media/cdrecorder'
the disk doesn't mount; instead there is a horrific spew of errors in
the system log, of the kind
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
(I'll attach the complete relevant part of the dmesg output).
/dev/hdc /media/cdrecorder auto
pamconsole,ro,exec,noauto,managed 0 0
The CD is mounted just fine if I instead specify the filesystem:
mount -t iso9660 /dev/cdrom /media/cdrecorder
However, once I get the error spew, the "eject" command only works as
root until I reboot the computer. Regular data CDs do mount correctly
later in the same session though, even as an ordinary user, they just
don't get ejected - the error output is exactly the same as in the
original posting.
Created attachment 107030 [details]
Error log from dmesg
This is the dmesg output when the CD fails to mount.
While tracking down another unrelated issue, I noticed that there are apparently some problems with the drive on boot. On each boot, the following appears in the kernel log: localhost kernel: cdrom: open failed. Not sure if this is related or something else, but felt it worthy of a mention. Initially after upgrading from FC2, I couldnt use my CD drive for some
reason (didnt explore too much). I decided to add "hdc=ide-scsi" and
could then work comfortably. However, I kept on getting boot log
messages that ide-scsi is deprecated and I should use ide-cd instead.
And so I did make the required change (hdc=ide-scsi) in grub.
Now the CD is completely inaccessible. K3b cant find any CD, even
though cdrecord can find it just fine:
=======================
$ cdrecord -scanbus
scsibus1:
1,0,0 100) 'SONY ' 'CD-RW CRX230ED ' '4YS1' Removable CD-ROM
=======================
Eject doesnt work.
While boot time, the kernel does recognize the device, any attempts to
read the device later gives the following problem:
============================================================
Nov 21 01:00:14 pluto kernel: device-mapper: 4.1.0-ioctl (2003-12-10)
initialised: dm.com
Nov 21 01:00:14 pluto kernel: hdc: command error: status=0x51 {
DriveReady SeekComplete Error }
Nov 21 01:00:14 pluto kernel: hdc: command error: error=0x54
Nov 21 01:00:14 pluto kernel: ide: failed opcode was 100
Nov 21 01:00:14 pluto kernel: end_request: I/O error, dev hdc, sector
=============================================================
For the time being I am going back to ide-scsi.
It appears that leaving the CD drive *empty* for a long time (overnight) causes some sort of timeout because when I wake up in the morning, I can use the eject button on the drive to open it. However, after inserting a new disc, behavior reverts back to abnormal. Doing an 'init 3' after "locking" the CD drive allows it to be ejected with the drive button. Inserting a CDDA/Data disc then again locks the drive. Doing a 'eject hdc' ejects it. However, after that normal operation is possible. Is this some strange udev/automount/kernel issue? eject failing on "corrupt" CD/DVDs might be covered by bug 139243 The warning message "deprecated SCSI ioctl" is covered by bug 141402 This bug might be related to bug 137831 Re: possibly being covered by bug 139243, I'm still seeing this when HAL is not running. I have the same problem here (Fedora Core 3 with all patches, but exactly the same happened to me with Fedora Core 2 as well). When ripping certain audio CDs (enhanced CDs?) with Grip (version doesn't matter), the CD cannot be ejected afterwards without super-user privileges. The CD is not mounted or otherwise blocked in an obvious way. Is there any workaround to make it work again without a reboot? It is a little bit annoying if normal users cannot use the CD drive any longer and not even the super-user can fix this. ;-) Haven't found anything helpful in other related bugs. BTW: Bug 142782 seems to be a duplicate of this one. An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you. Some months ago I migrated that machine to another distro, and so I no longer have a Fedora installation to test. Oddly enough, though, I'm having the same problem on the other distro... I need to poke around in thei bug database sometime and see what I can find. This isn't uncommon btw. I frequently see people file bugs, and later move to a different distro, and find things work for them. Then, their new distro does a kernel update to bring it to the same version the Fedora kernel was on, and their problems return. (Of course, they usually don't mention this in our bugzilla ;) The Fedora kernel is usually not patched as heavily as some other distributions so a lot of bugs end up being inherited directly from the kernel.org kernels that every distro bases off. Given you've repeated it on two seperate distributions, I'd recommend filing an upstream kernel bug at http://bugme.osdl.org Thanks for the update. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 Epiphany/1.4.4 Description of problem: When attempting to eject certain CDs or DVDs, `eject` fails. I first encountered this after extracting tracks from an "enhanced" CD (a music CD with music and other interactive content) with Sound Juicer; Sound Juicer reported "Could not eject the CD Reason: Input/output error". In testing with different discs this appears to consistently happen with DVDs and with "enhanced" audio CDs. After one occurrence, the problem seems to persist with any disc inserted, regardless of type, and only goes away after a reboot. Output of `eject -v` in this situation is as follows: eject: device name is `/dev/hdc' eject: expanded name is `/dev/hdc' eject: `/dev/hdc' is not mounted eject: `/dev/hdc' is not a mount point eject: `/dev/hdc' is a multipartition device eject: trying to eject `/dev/hdc' using CD-ROM eject command eject: CD-ROM eject command failed eject: trying to eject `/dev/hdc' using SCSI commands eject: SCSI eject failed eject: trying to eject `/dev/hdc' using floppy eject command eject: floppy eject command failed eject: trying to eject `/dev/hdc' using tape offline command eject: tape offline command failed eject: unable to eject, last error: Invalid argument Pressing the eject button on the drive itself also fails, even though the disc is not mounted and `lsof` indicates no file on the device is open. `eject` fails with the above errors regardless of whether the device specified is '/dev/hdc' or as a symlink to that device, e.g., '/dev/cdrom', '/dev/dvd'. Ejection fails on '/media/cdrecorder' as well. Running `eject -v` as root outputs the above errors but it does work, leading me to believe that this may be a permissions problem. However, I have not been able to find a combination of permissions which allow a normal user to eject the disc and in any case the physical eject button on the drive should not be disabled. If the system is shut down, the drive's eject button begins working again as soon as the shutdown sequence begins. The system where this is occurring is an IBM Thinkpad G40 with TEAC DW-224E DVD/CD-RW drive, running a fresh install of FC3. I'll try to install on a different system later this week and see if it has the same problem. Version-Release number of selected component (if applicable): eject-2.0.13-10 How reproducible: Always Steps to Reproduce: 1. Insert a DVD or "enhanced" CD. 2. Attempt to eject it, either with `eject` or by pressing eject button. Actual Results: Disc is not ejected. Expected Results: Disc is ejected.