Based on Suse patch, originally from
Anna Bernathova <anicka@suse.cz>, May 2008
SG_IO completion status is weird but still well defined. You'll need
to check both host_status, driver_status and status to determine that
a command actually succeeded. -- Tejun Heo, May 2008
Note that we also need to check driver_status and sense_buffer to
detect situation when there is no medium. It's valid request to call
eject(8) for device with no medium.
References: https://bugzilla.novell.com/show_bug.cgi?id=358033
Signed-off-by: Anna Bernathova <anicka@suse.cz>
Signed-off-by: Karel Zak <kzak@redhat.com>
If user has inserted a disc into the drive, the drive will normally be
locked. When using eject command to eject the drive, we need to unlock
the door first, or the CDROMEJECT command will fail.
Though the 2nd attmpt to eject the drive with eject_scsi will succeed,
it actually does two things: first to unlock the door and then to eject
the tray, both with the SG_IO ioctl. The problem is, Linux SCSI driver
keeps track of if a device is in locked state or not, if we go with
SG_IO to do the unlocking, the driver will not be aware of the unlocking
and would think the drive is locked while actually it has already been
unlocked by the first SG_IO command.
Fix this by issuing a unlock door command before the CDROMEJECT command
in cdrom_eject. Prior to this fix, the following output is expected when
there is a disc inside:
[aaron@aaronlu util-linux-2.22.2]$ eject -v /dev/sr0
eject: device name is `/dev/sr0'
eject: /dev/sr0: mounted on /run/media/aaron/CD_ROM
eject: /dev/sr0: is whole-disk device
eject: /dev/sr0: is removable device
eject: /run/media/aaron/CD_ROM: unmounting
eject: /dev/sr0: trying to eject using CD-ROM eject command
eject: CD-ROM eject command failed
eject: /dev/sr0: trying to eject using SCSI commands
eject: SCSI eject succeeded
After this fix, the following output is expected:
[aaron@aaronlu util-linux-2.22.2]$ ./eject -v /dev/sr0
lt-eject: device name is `/dev/sr0'
lt-eject: /dev/sr0: mounted on /run/media/aaron/CD_ROM
lt-eject: /dev/sr0: is whole-disk device
lt-eject: /dev/sr0: is removable device
lt-eject: /run/media/aaron/CD_ROM: unmounting
lt-eject: /dev/sr0: trying to eject using CD-ROM eject command
lt-eject: CD-ROM eject command succeeded
And the SCSI device's locked state is correct now.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
main() expects this method to return 0 for failure and 1 for success, as
the other eject_*() methods do. Add the missing comparison of ioctl() >= 0
Signed-off-by: Dave Reisner <dreisner@archlinux.org>
Signed-off-by: Karel Zak <kzak@redhat.com>
sys-utils/eject.c:529:11: warning: declaration of 'str' shadows a previous local [-Wshadow]
sys-utils/eject.c:506:9: warning: shadowed declaration is here [-Wshadow]
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
* '2012wk23' of git://github.com/kerolasa/lelux-utiliteetit:
lsblk: use blkdev_scsi_type_to_name()
blkdev: add blkdev_scsi_type_to_name()
wipefs: use symbolic value for markup mode
eject: inform if CD-ROM drive is not ready
docs: clean up partx.8 manual
include: fix void pointer arithmetics warnings
sysfs: fix printf format warnings
build: fix unused parameter warnings
build: fix redundant redeclaration warnings
include: fix spurious list.h warnings
uuidd: use output redirection which works [checkbashisms]
blkid: fix realloc memory leak [cppcheck]
setarch: do not use -1 as array index [cppcheck]
One some platforms, the -T option can be unreliable (see reference bug
report for some examples). Instead, if the kernel supports the cdrom
status ioctl, use that to ask explicitly for the current tray status
and then open/close accordingly.
The eject_cdrom() func was reworked slightly, but none of the existing
callers care about the explicit normalization to [0,1] values, so have
it return the raw value so we can convert toggle_tray() over to using
that.
Finally, now that toggle_tray() uses a lot of helper functions, drop
the check on CDROMCLOSETRAY. The sub-functions take care of that.
Reference: https://bugs.gentoo.org/261880
Signed-off-by: Mike Frysinger <vapier@gentoo.org>