Your message dated Mon, 28 Dec 2020 00:07:37 +0100 with message-id <[email protected]> and subject line Re: Bug#753821: eject fails on CD/DVD drive and reports wrong error has caused the Debian Bug report #753821, regarding eject fails on CD/DVD drive and reports wrong error to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 753821: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753821 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: eject Version: 2.1.5+deb1+cvs20081104-13 Severity: important I should have reported this ages ago, sorry. :-( I've got a system with several CD/DVD drives in it, and they all show the same behaviour. I think there's a kernel bug with CD locking at the root of the main problem here, and I'll report another bug there. For a while after I start my system, "eject /dev/srX" works just fine. However, after some non-determined period it stops working reliably. What I'm seeing is an annoying badly-reported error: sledge:/home/steve/iso# eject /dev/sr1 eject: unable to eject, last error: Inappropriate ioctl for device sledge:/home/steve/iso# eject /dev/sr1 eject: unable to eject, last error: Inappropriate ioctl for device sledge:/home/steve/iso# eject /dev/sr1 eject: unable to eject, last error: Inappropriate ioctl for device sledge:/home/steve/iso# eject /dev/sr1 After the fourth attempt here, the eject call works. I've tried hitting the eject button on the drive itself, but no joy. As to reporting ENOTTY, that's just *wrong*. Running the same under strace, I can see a silliness here that is the cause: open("/dev/sr1", O_RDONLY|O_NONBLOCK) = 3 ioctl(3, CDROMEJECT, 0) = -1 EIO (Input/output error) ioctl(3, SG_GET_VERSION_NUM, 0x7fff2e8f387c) = 0 ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1e, 00, 00, 00, 00, 00], mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=10000, flags=0, status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=0, info=0}) = 0 ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1b, 00, 00, 00, 01, 00], mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=10000, flags=0, status=02, masked_status=01, sb[18]=[70, 00, 02, 00, 00, 00, 00, 0a, 3a, 00, bb, 00, 3a, 00, 00, 00, 00, 00], host_status=0, driver_status=0x8, resid=0, duration=4, info=0x1}) = 0 ioctl(3, FDEJECT, 0x7fff2e8f38b8) = -1 ENOTTY (Inappropriate ioctl for device) ioctl(3, MGSL_IOCGPARAMS or MMTIMER_GETRES or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 0x7fff2e8f3890) = -1 ENOTTY (Inappropriate ioctl for device) For some daft reason, eject looks to be trying ioctl(CDROMEJECT), getting EIO as a failure mode, then falling back to ioctl(FDEJECT) on the CD drive. That last failure is the cause for the ENOTTY error, and that is reported incorrectly instead of the EIO that is the first (and correct) error. -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages eject depends on: ii libc6 2.13-38+deb7u1 ii libdevmapper1.02.1 2:1.02.74-8 eject recommends no packages. Versions of packages eject suggests: ii cdtool 2.1.8-release-2 pn setcd <none> -- no debconf information
--- End Message ---
--- Begin Message ---Version: 2.36.1-3 * Steve McIntyre <[email protected]>: > Package: eject > Version: 2.1.5+deb1+cvs20081104-13 > Severity: important > > I should have reported this ages ago, sorry. :-( Sorry this took a while, too... [..] > As to reporting ENOTTY, that's just *wrong*. > > Running the same under strace, I can see a silliness here that is the cause: > > open("/dev/sr1", O_RDONLY|O_NONBLOCK) = 3 > ioctl(3, CDROMEJECT, 0) = -1 EIO (Input/output error) > ioctl(3, SG_GET_VERSION_NUM, 0x7fff2e8f387c) = 0 > ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1e, 00, 00, 00, 00, 00], > mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=10000, flags=0, status=00, > masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, > duration=0, info=0}) = 0 > ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[1b, 00, 00, 00, 01, 00], > mx_sb_len=32, iovec_count=0, dxfer_len=0, timeout=10000, flags=0, status=02, > masked_status=01, sb[18]=[70, 00, 02, 00, 00, 00, 00, 0a, 3a, 00, bb, 00, 3a, > 00, 00, 00, 00, 00], host_status=0, driver_status=0x8, resid=0, duration=4, > info=0x1}) = 0 > ioctl(3, FDEJECT, 0x7fff2e8f38b8) = -1 ENOTTY (Inappropriate ioctl for > device) > ioctl(3, MGSL_IOCGPARAMS or MMTIMER_GETRES or MTIOCTOP or > SNDCTL_MIDI_MPUMODE, 0x7fff2e8f3890) = -1 ENOTTY (Inappropriate ioctl for > device) > > For some daft reason, eject looks to be trying ioctl(CDROMEJECT), > getting EIO as a failure mode, then falling back to ioctl(FDEJECT) on > the CD drive. That last failure is the cause for the ENOTTY error, and > that is reported incorrectly instead of the EIO that is the first (and > correct) error. Right. I have checked the util-linux implementation (this one is used in bullseye), and the error reporting has changed now to: eject: unable to eject I can see that this is not great either, but running with -v gives: ... eject: /dev/sr0: trying to eject using floppy eject command eject: floppy eject command failed ... eject: unable to eject I'll consider this good enough for now, and mark it fixed for the version in bullseye. If you disagree, please reopen. Best, Chris
--- End Message ---
