eject -T doesn't close the tray

Bug #91873 reported by didier
44
This bug affects 1 person
Affects Status Importance Assigned to Milestone
eject (Debian)
Fix Released
Unknown
eject (Ubuntu)
Fix Released
High
Tim Gardner
Hardy
Fix Released
Undecided
Unassigned
Intrepid
Fix Released
High
Tim Gardner

Bug Description

Binary package hint: eject

On my Macs ioctl(iCDROMEJECT) returns EIO if there's no disk in the drive or the tray is open and eject doesn't try to close it.

Revision history for this message
didier (did447-deactivatedaccount) wrote :

Patch attached.

Revision history for this message
Andrew Flegg (aflegg) wrote :

This isn't just a Mac issue, I see the same behaviour on X86_64 (Linux serenity 2.6.20-16-generic #2 SMP Thu Aug 30 23:16:15 UTC 2007 x86_64 GNU/Linux)

andrew@serenity:~$ eject -v -T
eject: using default device `cdrom'
eject: device name is `cdrom'
eject: expanded name is `/dev/cdrom'
eject: `/dev/cdrom' is a link to `/dev/hda'
eject: `/dev/hda' is not mounted
eject: `/dev/hda' is not a mount point
eject: toggling tray
ioctl: Input/output error

Revision history for this message
noisymime (josh-noisymime) wrote :

This seems to be an issue accross the board. I'm on x86_32 and receive the following:
eject -v -T /dev/dvd
eject: device name is `/dev/dvd'
eject: expanded name is `/dev/dvd'
eject: `/dev/dvd' is a link to `/dev/scd0'
eject: `/dev/scd0' is not mounted
eject: `/dev/scd0' is not a mount point
eject: toggling tray
ioctl: Input/output error

This command works fine for ejecting and 'eject -t' will close the tray without a problem, however the '-T' option does not function correctly.

Revision history for this message
Andrew Flegg (aflegg) wrote :

An addendum: the patch works for me.

Revision history for this message
xtknight (xt-knight) wrote :

Here is a debdiff for Hardy. It fixes the problem for me.

Changed in eject:
status: New → Confirmed
Revision history for this message
Daniel Holbach (dholbach) wrote :

Tim: can you please take a look at it?

Revision history for this message
noisymime (josh-noisymime) wrote :

debdiff above from xtknight tested OK on Hardy for me. -T works as expected once applied.

Revision history for this message
aalonso (aalonso00) wrote :

In my case the cdrom tray refuse to open or close either by pressing the cdrom eject button or by using eject command; after applying the patch provided by xtknight I'm still experiencing the same problem. I try several options with eject command and notice that if I use the "-s" option (using SCSI) i get the next result:

aalonso@aalonso-linux:~$ eject -v -s /dev/dvd
eject: device name is `/dev/dvd'
eject: expanded name is `/dev/dvd'
eject: `/dev/dvd' is a link to `/dev/scd0'
eject: `/dev/scd0' is not mounted
eject: `/dev/scd0' is not a mount point
eject: `/dev/scd0' is not a multipartition device
eject: trying to eject `/dev/scd0' using SCSI commands
eject: SCSI eject succeeded

But still cdrom doen't eject, find attached a hardware description of my pc, and find below the steps to apply the patch:

sudo mkdir /usr/local/src/eject

cd /usr/local/src/eject

sudo deb apt-get source eject

cd eject-2.1.5

sudo wget http://launchpadlibrarian.net/13309417/eject_2.1.5-6ubuntu1.debdiff

sudo patch -p1 < eject_2.1.5-6ubuntu1.debdiff

sudo apt-get build-dep eject

sudo apt-get install devscripts build-essential fakeroot

sudo debuild -us -uc

sudo dpkg --install ../eject_2.1.5-6ubuntu1_*.deb

Revision history for this message
Belcirelk (beliveau) wrote :

I confirm that the patch works for me on a Intel Mac with Ubuntu Hardy 64 bits.

Revision history for this message
Tim Gardner (timg-tpi) wrote :

SRU Justification

Impact: Can't close the CD tray using eject -T

Patch: Check for (-EIO) when sending CDROMEJECT ioctl.

Patch: http://launchpadlibrarian.net/13309417/eject_2.1.5-6ubuntu1.debdiff

Test Case: see bug description

Revision history for this message
Tim Gardner (timg-tpi) wrote :

Uploaded eject_2.1.5-6ubuntu1

Changed in eject:
assignee: nobody → timg-tpi
importance: Undecided → Low
milestone: none → ubuntu-8.04.2
status: Confirmed → Fix Committed
Revision history for this message
Steve Langasek (vorlon) wrote :

Are there conceivably cases where ignoring EIO as a non-failure will /not/ do the right thing here, and instead cause a regression?

Accepting into -proposed, but I would appreciate seeing some discussion of how we know this won't cause regressions for users not affected by the current problem before it goes to -updates.

Changed in eject:
status: New → Fix Committed
Revision history for this message
Steve Langasek (vorlon) wrote :

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in eject:
milestone: ubuntu-8.04.2 → none
Revision history for this message
Steve Beattie (sbeattie) wrote :

I have reproduced the original problem in the 2.1.5-6 version of eject included in the 8.04 release, and verified that the eject package in hardy-proposed, 2.1.5-6ubuntu1, does indeed successfully close the cdrom drive when 'eject -T' is invoked. The relevant strace output from the original version was so:

  open("/dev/scd0", O_RDWR|O_NONBLOCK) = 3
  gettimeofday({1219707308, 553806}, NULL) = 0
  ioctl(3, CDROMEJECT, 0) = -1 EIO (Input/output error)

and the fixed version's strace looked like when -T was given:

  ioctl(3, CDROMEJECT, 0) = -1 EIO (Input/output error)
  gettimeofday({1219706590, 522464}, NULL) = 0
  ioctl(3, CDROMCLOSETRAY, 0xb7eae0c6) = 0
  exit_group(0) = ?

Note that 'eject -t' in both versions only invokes the CDROMCLOSETRAY ioctl(). Also note that the original version of 'eject -T' would report the returned EIO error when successfully ejecting a closed drive, but the updated version, while also opening the door, silently ignores the returned EIO, matching the behavior both versions of eject without arguments on a closed drive. Here's the straace output from running 'eject' on a closed drive:

  open("/dev/scd0", O_RDWR|O_NONBLOCK) = 3
  ioctl(3, CDROMEJECT, 0x3) = -1 EIO (Input/output error)
  ioctl(3, SG_GET_VERSION_NUM, 0xbf91f574) = 0
  ioctl(3, SG_IO, 0xbf91f520) = 0
  ioctl(3, SG_IO, 0xbf91f520) = 0
  ioctl(3, SG_IO, 0xbf91f520) = 0
  ioctl(3, BLKRRPART, 0xbf91f560) = -1 EINVAL (Invalid argument)
  close(3) = 0
  exit_group(0) = ?

It's unclear to me why the kernel would return EIO on a successful CDROMEJECT event, and it's also unclear to me eject is doing further queries on the device.

I'm marking this bug as verification-done, because I think the fix causes eject -T to work in more situations than it does in the released version, and other invocations of eject continue to work as they did before, but it seems to me that the kernel<->eject interface needs to be re-examined.

Revision history for this message
Steve Beattie (sbeattie) wrote :

Based on positive feedback received in that report, this update may address the issue in https://bugs.launchpad.net/bugs/37785 as well.

Revision history for this message
Martin Pitt (pitti) wrote :

Tim, please upload this to intrepid ASAP.

Changed in eject:
importance: Low → High
Revision history for this message
Tim Gardner (timg-tpi) wrote :

Martin - uploaded Intrepid eject_2.1.5-9ubuntu1

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eject - 2.1.5-9ubuntu1

---------------
eject (2.1.5-9ubuntu1) intrepid; urgency=low

  * Fix problem where eject -T doesn't close the tray. (LP: #91873)
  * Modify Maintainer value to match the DebianMaintainerField
    specification.

 -- Andy Matteson <email address hidden> Mon, 01 Sep 2008 12:42:09 -0600

Changed in eject:
status: Fix Committed → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :

Copied to hardy-updates.

Changed in eject:
status: Fix Committed → Fix Released
Revision history for this message
Ondřej Surý (ondrej) wrote :
Revision history for this message
Zartan (mattik-deactivatedaccount) wrote :

I still cannot eject cdrom in Kubuntu Intrepid.

Revision history for this message
Zartan (mattik-deactivatedaccount) wrote :

If I press eject by Desktop or I write eject or sudo eject in konsole cdrom bay open and it close just after this. I cannot take out cdrom.

Revision history for this message
Martin Pitt (pitti) wrote :

Matti, your problem is bug 280931.

Changed in eject:
importance: Undecided → Unknown
status: New → Unknown
Changed in eject:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.