From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Firefox/1.0.2 Fedora/1.0.2-3 Description of problem: ipod mounts and umounts fine, but the eject command does not work (see below). The ipod continues to display the "Do not disconnect" message until i remove the USB modules using "modprobe -r". [root@jeffslaptop media]# eject -v /media/ipod eject: device name is `/media/ipod' eject: expanded name is `/media/ipod' eject: `/dev/sda2' is mounted at `/media/ipod' eject: unmounting device `/dev/sda2' from `/media/ipod' eject: `/dev/sda2' is a multipartition device eject: trying to eject `/dev/sda2' using CD-ROM eject command eject: CD-ROM eject command failed eject: trying to eject `/dev/sda2' using SCSI commands eject: SCSI eject failed eject: trying to eject `/dev/sda2' using floppy eject command eject: floppy eject command failed eject: trying to eject `/dev/sda2' using tape offline command eject: tape offline command failed eject: unable to eject, last error: Invalid argument Version-Release number of selected component (if applicable): kernel-2.6.11-1.1236_FC4 How reproducible: Always Steps to Reproduce: 1. Plug in / mount the ipod 2. Try to eject the ipod Actual Results: see above error message from "eject", ipod continues to display "do not disconnect" Expected Results: eject works, does not report an error, and the ipod no longer says "do not disconnect" Additional info: Big filed against kernel at request of davidz, see comments in bug 132195.
eject won't work whilst its still mounted. You'll need to umount it first.
Actually the as seen in the bug description eject(1) actually unmounts before ejecting and the man page for eject(1) agrees with that. Further a) this worked with earlier kernels; and b) bug 132195 suggests that unloading the ehci_hdc kernel module makes things right. So, this bug pretty much blocks bug 132195. Cheers, David
I'm puzzled. From comment #1 it appears that the users ipod rejects all 4 methods of eject. Could it be that some ipods support this and some don't ? It seems bizarre that any model would need this anyway. What exactly 'ejects' when this succeeds ?
I've got an iPod mini and this happens for both USB2 and Firewire connections (both USB Storage and SBP2 protocols support the notion of eject, mainly for optical and zip drives etc); I think it stopped working around 2.6.10. The effect of ejecting an iPod is that it changes the display from "Do not disconnect" to "Safe to disconnect". I agree it's pretty ugly :-)
Btw, I think this applies to all iPod generations but ICBW.
According to Pete Zaitcev log entry from 2005-03-03 here http://www.livejournal.com/users/zaitcev/ ub actually does the right thing for iPod's; Pete, any idea what usb-storage and sbp2 is doing wrong (since 2.6.9 or so) since they refuse to eject and show the "OK to disconnect" dialog?
This is a more precise location for the blog entry: http://www.livejournal.com/users/zaitcev/2005/03/03/ Yes, eject works with ub, at least with 2.6.12-rc1 (tested a minute ago). However, all ub does is calling scsi_cmd_ioctl() which processes ioctls and passes them down to a transport. It ought to be common with sd_mod & sbp2. I'll have a closer look.
Well, how about now? [root@niphredil zaitcev]# eject -v /dev/sda2 eject: device name is `/dev/sda2' eject: expanded name is `/dev/sda2' eject: `/dev/sda2' is not mounted eject: `/dev/sda2' is not a mount point eject: `/dev/sda2' is a multipartition device eject: trying to eject `/dev/sda2' using CD-ROM eject command eject: CD-ROM eject command succeeded [root@niphredil zaitcev]# cat /proc/version Linux version 2.6.11-1.1305_FC4 (bhcompile.redhat.com) (gcc version 4.0.0 20050512 (Red Hat 4.0.0-5)) #1 Fri May 13 14:01:24 EDT 2005 [root@niphredil zaitcev]#
Sorry, it doesn't work with my iPod Mini (1st gen iPod Mini) [root@daxter ~]# eject -v /dev/sda2 eject: device name is `/dev/sda2' eject: expanded name is `/dev/sda2' eject: `/dev/sda2' is mounted at `/media/ipod' eject: unmounting device `/dev/sda2' from `/media/ipod' eject: `/dev/sda2' is a multipartition device eject: trying to eject `/dev/sda2' using CD-ROM eject command eject: CD-ROM eject command failed eject: trying to eject `/dev/sda2' using SCSI commands eject: SCSI eject failed eject: trying to eject `/dev/sda2' using floppy eject command eject: floppy eject command failed eject: trying to eject `/dev/sda2' using tape offline command eject: tape offline command failed eject: unable to eject, last error: Invalid argument [root@daxter ~]# uname -a Linux daxter.boston.redhat.com 2.6.11-1.1323_FC4 #1 Thu May 19 03:20:21 EDT 2005 i686 i686 i386 GNU/Linux
David, please attach "strace eject /media/ipod" output, cat /proc/mounts output, and unedited /var/log/messages (please do not drop into comments box). For some reason, I'm unable to reproduce it. So we'll do two-pronged attack. 1. Get info from David's install and have him running tests (although Jeff should be doing this as a requestor). 2. Find out what's different with my setup.
Created attachment 114831 [details] contents of /var/log/messages As requested...
Created attachment 114832 [details] output of /proc/mounts as requested...
Created attachment 114833 [details] output of "strace eject /media/ipod" as requested...
I'm stunned by the -EIO. No idea how that could have happened...
I'm seeing the same behaviour on FC4t3 (kernel-2.6.11-1.1286_FC4) with a new 4th gen iPod (USB). Using eject umounts the volume but "Do not disconnect" stays on the iPod's screen. I see the same behaviour with the same iPod and hardware on FC3 (latest kernel). For what it's worth here's the eject output: # eject -v /media/ipod/ eject: device name is `/media/ipod' eject: expanded name is `/media/ipod' eject: `/dev/sda2' is mounted at `/media/ipod' eject: unmounting device `/dev/sda2' from `/media/ipod' eject: `/dev/sda2' is a multipartition device eject: trying to eject `/dev/sda2' using CD-ROM eject command eject: CD-ROM eject command failed eject: trying to eject `/dev/sda2' using SCSI commands eject: SCSI eject failed eject: trying to eject `/dev/sda2' using floppy eject command eject: floppy eject command failed eject: trying to eject `/dev/sda2' using tape offline command eject: tape offline command failed eject: unable to eject, last error: Invalid argument Using umount instead makes no difference. The iPod still displays "Do not disconnect".
FWIW, I think this: ioctl(3, CDROM_SEND_PACKET, 0xbfba03ac) = 0 ioctl(3, CDROM_SEND_PACKET, 0xbfba03ac) = -1 EIO (Input/output error) is just an strace bug. If I do "eject -s /dev/sda3", then its the second ioctl that fails. Looking at the eject code, the failed ioctl should actually be SCSI_IOCTL_SEND_COMMAND/START_STOP eject -s /dev/sda3 works fine for me on FC3, but not FC4
the bug is present in fc4: kernel-2.6.11-1.1369_FC4, eject-2.0.13-15 with a 4th Gen iPod
As a data point I don't have success ejecting my USB Zip Drive either: kernel-2.6.11-1.1383_FC5 eject-2.0.13-15 on Rawhide on a ppc (Powerbook G4 12"). If requested, I can post logs when I get home.
I happen to have an original ZIP-100 USB drive. I just did "yum update", here's the result: [zaitcev@niphredil ~]$ eject /dev/sda eject: unable to open `/dev/sda' [zaitcev@niphredil ~]$ su Password: [root@niphredil zaitcev]# eject -v /dev/sda eject: device name is `/dev/sda' eject: expanded name is `/dev/sda' eject: `/dev/sda' is not mounted eject: `/dev/sda' is not a mount point eject: `/dev/sda' is a multipartition device eject: trying to eject `/dev/sda' using CD-ROM eject command eject: CD-ROM eject command succeeded [root@niphredil zaitcev]# strace -o /tmp/xxx eject /dev/sda [root@niphredil zaitcev]# grep ioctl /tmp/xxx ioctl(3, CDROMEJECT, 0x84c88a0) = 0 [root@niphredil zaitcev]# cat /proc/version Linux version 2.6.12-1.1387_FC5 (bhcompile.redhat.com) (gcc version 4.0.0 20050616 (Red Hat 4.0.0-12)) #1 Mon Jun 20 17:39:34 EDT 2005 [root@niphredil zaitcev]# rpm -q eject hal udev eject-2.0.13-15 hal-0.5.2-2 udev-058-1 [root@niphredil zaitcev]# I think at this point the only clue is the EIO which Jeff and Mark got. It is wrong. EINVAL and ENOTTY are ok, but not EIO. David, please get me strace when you have a chance; I want to verify that it breaks with EIO for you. BTW, ppc is big endian but I do not expect a problem there.
Jeff (or anyone who can reproduce this): Please try the eject version 2.0.13-15.bz154955.1 from this URL: ftp://people.redhat.com/zaitcev/154955/ (I self-built it, so there's no ppc version for David's laptop)
I still have the same problem after installing eject 2.0.13-15.bz154955.1. FWIW, worked perfectly under FC3 for me.
I suppose this was too easy to work. Rob, please attach your strace and dmesg while you're hot on it, even if they look just like David's and Jeff's. But wait, there's also one more thing I'd like to see. We have usbmon available now. A usbmon trace would help. Here's how it's taken: modprobe usbmon mount -t debugfs none /sys/kernel/debug cat /sys/kernel/debug/usbmon/1t > /tmp/mon.trace <--- actually it's the bus number, same as in /proc/bus/usb/devices The best is to get all three consistently. That is... 1. Start cat from usbmon 2. run strace -o /tmp/s.trace eject 3. Kill cat, save the file 4. dmesg > dmesg.out, save the file 5. save /tmp/s.trace Then attach all three. Then I'll meditate over them.
Created attachment 115964 [details] dmesg output dmesg output
Created attachment 115965 [details] strace output strace output
Created attachment 115966 [details] usbmon usbmon (hope i got this one right...)
OK, this is a little clearer now. The ASC/Q 53/2 is "Medium removal prevented". It seems to hint that either our SCSI stack or one of applications issued "lock the door" command. We normally do it when a device is mounted.
Someone please install 2.0.13-15.bz154955.2 from this URL: ftp://people.redhat.com/zaitcev/154955/ Then, run it like this: strace -o /tmp/s.trace eject -vs If it fails, repeat. I am asking this to test my door refcount hypothesis. My SCSI standard hints that devices have to count them. That is probably why Rob's iPod throws an ASC/Q 53/2 on us.
Created attachment 115978 [details] strace using eject-2.0.13-15.bz154955.2 seems to fix the problem
Beautiful, now works for me as well.
N.B. The eject-2.0.13-15.bz154955.2 is not a candidate fix. It is a test program to verifty my deductions. The scenario appears that the devices count the number of "lock the door" commands and expect an equal number of "unlock the door" commands, minus one, before the eject works. I have not figured where the extra command comes from. It is clear that if HAL attempts to lock or unlock doors, with a packet command or even with SCSI_IOCTL_DOORLOCK, this will wreak havoc with refcounts (inside the device). But I do not know if this actually happens, and if it does, how this manages to be time-sensitive.
eject-2.0.13-15.bz154955.2 works for me on ppc for both my iPod mini and my USB Zip drive; thanks! > I have not figured where the extra command comes from. It is clear that > if HAL attempts to lock or unlock doors, with a packet command or even > with SCSI_IOCTL_DOORLOCK, this will wreak havoc with refcounts (inside > the device). But I do not know if this actually happens, and if it does, > how this manages to be time-sensitive. hal does no such thing but it does trigger events that may lead to other software mounting and unmounting the device which should be safe. Btw, the only place hal does raw packets to devices is to retrieve VPD and that's only for optical drives (to figure out what the drive can do), IDE hard drives (page 0x80 stuff to get the serial number etc.) and SCSI drives (to get serial numbers). Btw, you should be able to reproduce the bug without hal. Thanks again.
I agree, implicating HAL is a logical lapse. We know that the failure continues to happen with haldaemon stopped, at least for some users. Mental note: try with udev stopped too, or echo /bin/true > /proc/sys/kernel/hotplug
ok tried with hal stopped and 'echo /bin/true to /proc/sys/kernel/hotplug' still doesn't want to eject
with udevd killed also still not ejecting
something not good is happening, the ipod is not seeing any of it's music (don't fret too much, I have everything on my hdd), I've not mounted the ipod whilst I've been trying any of this
resetting the ipod fixed this, I blame the hardware manufacturer ;-)
Mass update of -test bugs to update version to fc4. (Please retest on final release, and report results if you have not already done so). Thanks.
still present on fc4
[This comment has been added as a mass update for all FC4 kernel bugs. If you have migrated this bug from an FC3 bug today, ignore this comment.] Please retest your problem with todays 2.6.12-1.1398_FC4 update. If your problem involved being unable to boot, or some hardware not being detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE* installing any kernel updates. If in doubt, you can recreate this file using.. mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak mv /etc/modprobe.conf /etc/modprobe.conf.bak kudzu Thank you.
Please ignore the mass update. Meanwhile, my evil plans has come to fruition. Please install 2.6.12-1.1433_FC5, and make sure eject still fails. Then do this: - install old eject (or make sure to use saved binary) - Plug - Look at /proc/bus/usb/devices and note the bus number Bus=XX in T: line - Unplug - mount /sys/kernel/debug - Start cat /sys/kernel/debug/usbmon/1t > run.mon or 2t or 3t, depending on bus number - Plug iPod - eject -r (should fail) - Unplug - Interrupt cat Attach resulting run.mon and dmesg, or simply send them to me. (keeping the bug in needinfo)
To clarify, Rob got me a usbmon trace once already, in comment #25. However, at that time usbmon was unable to get me SCSI commands. DaveJ added a little patchlet to let it work better in current builds.
I have been doing a lot of hacking with customized printk calls in the kernel, enabling verbose scsi logging, USB logging and USB storage logging. Oh, and KDB. The problem can be reproduced without HAL (service haldaemon stop). My conclusion is that PREVENT MEDIUM REMOVAL is sent when the device is opened by eject, because the kernel routine sd_open() (drivers/scsi/sd.c) calls scsi_set_medium_removal(sdev, SCSI_REMOVAL_PREVENT). This makes sense because usually you don't want the user to remove a medium while some application has it open. However, it does cause this problem with eject, because eject needs to get a file handle on which to issue the necessary ioctl(). So, for the time being I reckon the patched eject-2.0.13-15.bz154955.2 is the way to go (unless you can somehow queue up "eject" calls in the kernel until the device is closed?) Peter Wainwright
I know about the lock-door-on-open. There are a few problems with this theory, unfortunately. The problem one is how the issue comes and goes for same people with same devices. I saw it a couple of times myself, although most of the time everything worked. This may be discounted by arguing that perhaps some other bug prevented ejection for me, and my iPod simply ignores lock-the-door command or something like that, and firmware is different in iPods which fail. I disagree, but in any case, problem two is the ZIP. This is a device guaranteed to be the same, works for me, fails for David Zeuten. And the difference is ...? I suspect that lock-on-open plays a role but it's nowhere as straightforward. See comment #30. It would be nice if someone acted upon comment #40.
I see this is not going anywhere. Why sudden lack of interest? I still need a good trace as per comment #40, but also there's a simpler idea. Let's just mark iPods as non-removable (which is what they are, actually). Someone who still has this happening (reliably), please attach their /proc/bus/usb/devices. I need your PID/VID and firmware for unusual_devs.h.
Created attachment 117940 [details] usbmon as per comment 40
Created attachment 117941 [details] dmesg as per comment 40
Thanks, Rob. What about /proc/bus/usb/devices? BTW, this is a request which everyone should join unless their iPod yields the same VID/PID/Firmware IDs as one of previous posters.
Created attachment 117951 [details] /proc/bus/usb/devices as per comment 44
Come on, guys, anyone besides Rob? Or EVERYONE on this list has got a 05ac/1204/0.02 combo? Now that would be Really Suggestive (of a bug in Apple's firmware). Actually, the way it's now in Linux, firmware level is not important, because I want to put the flag into common iPod entries, and they have wildcards for firmware. But no matter, just give me a few more, so I know if it makes sense to limit this to a particular model.
The 'eject' command included in the eject rpm issued by Fedora Base is faulty. http://rpm.pbone.net/index.php3/stat/4/idpl/2023305/com/eject-2.0.13-15.1.i386.rpm.html The 'eject' rpm on this page solves the problem. It is important to remember that the command 'eject /dev/sda' should be performed as root and with the Ipod mounted. The command does not work if the Ipod is unmounted first. I use a 60G Ipod w/ Colour Display - aka 4th Gen 2nd edition photo.
The suggestion about ejecting while mounted is very suspicious. If eject fails to work if device is not mounted, something is very broken. I reviewed Than's changes and I agree. Comparing with my test eject, he added stopping the device. I suppose if this is the direction eject is going to take, no kernel changes are needed for Fedora specifically, but it remains to be seen what "upstream" direction eject takes (and it upstream exists for it).
See bug 158548 for changes in eject(1).
To summarize, I had something like this in mind: --- linux-2.6.13-rc6/drivers/usb/storage/unusual_devs.h 2005-08-14 20:57:45.000000000 -0700 +++ linux-2.6.13-rc6-lem/drivers/usb/storage/unusual_devs.h 2005-08-23 13:49:27.000000000 -0700 @@ -530,12 +540,22 @@ UNUSUAL_DEV( 0x05ab, 0x5701, 0x0100, 0x * 0x1204. They just need the US_FL_FIX_CAPACITY. As the bcdDevice appears * to change with firmware updates, I changed the range to maximum for all * iPod entries. + * The US_FL_NOT_LOCKABLE comes from Pete Zaitcev <zaitcev>. + * It originates in RH bz#154955. Basically, iPod refuses to honor + * MEDIA LOAD UNLOAD (eject -s /dev/sda) if it had "door locked" with + * PREVENT ALLOW MEDIA REMOVAL. Which is what we do for all device opens + * on removable devices, and iPod reports itself as removable (Which is + * wrong: it has not removable media of any sort. Stupid Apple!). + * Note that this is purely cosmetic. It appears safe to unplug iPods + * which were not properly ejected. But users love to see the check mark + * and the "OK To Disconnect" message. They feel warm and fuzzy, and this + * is what Linux is about, right? */ UNUSUAL_DEV( 0x05ac, 0x1202, 0x0000, 0x9999, "Apple", "iPod", US_SC_DEVICE, US_PR_DEVICE, NULL, - US_FL_FIX_CAPACITY ), + US_FL_FIX_CAPACITY | US_FL_NOT_LOCKABLE ), /* Reported by Avi Kivity <avi.il> */ UNUSUAL_DEV( 0x05ac, 0x1203, 0x0000, 0x9999 But if Than's approach is adopted instead, it is fine with me. He needs new eject for non-USB devices anyway.
*** Bug 132195 has been marked as a duplicate of this bug. ***
Relevant /proc/bus/usb/devices section for a 20GB 4th gen iPod. I'm still seeing this problem on updated FC4: eject-2.1.1-0.fc4.1, kernel-2.6.12-1.1398_FC4. T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=05ac ProdID=1203 Rev= 0.01 S: Manufacturer=Apple S: Product=iPod S: SerialNumber=000000AEFB30 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
What is the situation on FC-5? Everything works, no?
Pete, yup, I think we are good here. It works for me both on the iPod Mini and iPod Nano both via USB and Firewire (the nano doesn't do firewire though). Additionally, the desktop bits (gnome-mount) got enough smarts to actually issue the eject when you unmount from the desktop. So I'd say we're in pretty good shape.
Works here on fc5 if the ipod (4:th gen) is hotplugged but not if it is coldplugged i.e present when the computer boots up.
On FC5, eject works perfectly if the ipod's filesystem is mounted, and the ipod reports it's safe to disconnect. If the ipod's filesystem is not mounted, the eject command hangs in device wait for 30 seconds-ish and then reports: eject: unable to eject, last error: No such device This is usb-2.0, ipod 5g (video), kernel 2.6.16-1.2111_FC5. Eject command: eject /media/IPOD Eject command when not mounted: eject /dev/sdb
That's because eject tries various methods of ejection. The eject -s should not wait. Can I close this? Jeff, it's up to you.
Works for me on FC5. Apologies for not watching this discussion more closely earlier.
OK, I'm closing this. I am aware that we have other issues, e.g. the disparity between ub and usb-storage, the -71 thrown upon eject, and the confusion in Nautilus GUI between "Umount" and "Eject". But as far as this bug goes, the eject -s seems to be working. Everyone, please file new bugs for specific failure scenarios, I'll triage and dup as necessary.