|Summary:||eject command does not make ipod safe for removal|
|Product:||[Fedora] Fedora||Reporter:||Jeff Pearson <rh>|
|Component:||kernel||Assignee:||Pete Zaitcev <zaitcev>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Brian Brock <bbrock>|
|Version:||5||CC:||andda347, byte, davidz, jeroen, markmc, menno, moneta.mace, nmanojlovic, peter.wainwright, robb, robkore, than, zaitcev, zing|
|Fixed In Version:||FC-5||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-07-12 01:43:24 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Jeff Pearson 2005-04-15 01:57:58 UTC
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.
Comment 1 Dave Jones 2005-04-15 02:03:57 UTC
eject won't work whilst its still mounted. You'll need to umount it first.
Comment 2 David Zeuthen 2005-04-15 02:12:02 UTC
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
Comment 3 Dave Jones 2005-04-15 02:27:21 UTC
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 ?
Comment 4 David Zeuthen 2005-04-15 02:38:38 UTC
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 :-)
Comment 5 David Zeuthen 2005-04-15 02:39:36 UTC
Btw, I think this applies to all iPod generations but ICBW.
Comment 6 David Zeuthen 2005-04-15 03:06:28 UTC
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?
Comment 7 Pete Zaitcev 2005-04-15 05:30:51 UTC
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.
Comment 8 Pete Zaitcev 2005-05-19 04:37:29 UTC
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 (firstname.lastname@example.org) (gcc version 4.0.0 20050512 (Red Hat 4.0.0-5)) #1 Fri May 13 14:01:24 EDT 2005 [root@niphredil zaitcev]#
Comment 9 David Zeuthen 2005-05-20 17:15:07 UTC
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
Comment 10 Pete Zaitcev 2005-05-20 23:14:25 UTC
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.
Comment 11 Jeff Pearson 2005-05-25 15:33:04 UTC
Created attachment 114831 [details] contents of /var/log/messages As requested...
Comment 12 Jeff Pearson 2005-05-25 15:34:07 UTC
Created attachment 114832 [details] output of /proc/mounts as requested...
Comment 13 Jeff Pearson 2005-05-25 15:34:57 UTC
Created attachment 114833 [details] output of "strace eject /media/ipod" as requested...
Comment 14 Pete Zaitcev 2005-06-07 23:54:56 UTC
I'm stunned by the -EIO. No idea how that could have happened...
Comment 15 Menno Smits 2005-06-08 10:31:19 UTC
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".
Comment 16 Mark McLoughlin 2005-06-15 09:01:38 UTC
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
Comment 17 Robert Brooks 2005-06-21 08:55:44 UTC
the bug is present in fc4: kernel-2.6.11-1.1369_FC4, eject-2.0.13-15 with a 4th Gen iPod
Comment 18 David Zeuthen 2005-06-21 17:16:35 UTC
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.
Comment 19 Pete Zaitcev 2005-06-21 22:03:20 UTC
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 (email@example.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.
Comment 20 Pete Zaitcev 2005-06-24 21:03:29 UTC
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)
Comment 21 Rob Murphy 2005-06-24 23:16:34 UTC
I still have the same problem after installing eject 2.0.13-15.bz154955.1. FWIW, worked perfectly under FC3 for me.
Comment 22 Pete Zaitcev 2005-06-24 23:51:42 UTC
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.
Comment 23 Rob Murphy 2005-06-25 00:44:01 UTC
Created attachment 115964 [details] dmesg output dmesg output
Comment 24 Rob Murphy 2005-06-25 00:45:18 UTC
Created attachment 115965 [details] strace output strace output
Comment 25 Rob Murphy 2005-06-25 00:46:58 UTC
Created attachment 115966 [details] usbmon usbmon (hope i got this one right...)
Comment 26 Pete Zaitcev 2005-06-25 03:00:11 UTC
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.
Comment 27 Pete Zaitcev 2005-06-25 18:54:22 UTC
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.
Comment 28 Robert Brooks 2005-06-25 21:00:46 UTC
Created attachment 115978 [details] strace using eject-2.0.13-15.bz154955.2 seems to fix the problem
Comment 29 Rob Murphy 2005-06-25 21:31:39 UTC
Beautiful, now works for me as well.
Comment 30 Pete Zaitcev 2005-06-25 23:24:10 UTC
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.
Comment 31 David Zeuthen 2005-06-26 00:23:11 UTC
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.
Comment 32 Pete Zaitcev 2005-06-26 18:49:43 UTC
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
Comment 33 Robert Brooks 2005-06-26 20:22:23 UTC
ok tried with hal stopped and 'echo /bin/true to /proc/sys/kernel/hotplug' still doesn't want to eject
Comment 34 Robert Brooks 2005-06-26 20:28:17 UTC
with udevd killed also still not ejecting
Comment 35 Robert Brooks 2005-06-26 23:29:00 UTC
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
Comment 36 Robert Brooks 2005-06-26 23:33:44 UTC
resetting the ipod fixed this, I blame the hardware manufacturer ;-)
Comment 37 Dave Jones 2005-06-27 23:26:51 UTC
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.
Comment 38 Robert Brooks 2005-06-28 08:13:56 UTC
still present on fc4
Comment 39 Dave Jones 2005-07-15 21:44:49 UTC
[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.
Comment 40 Pete Zaitcev 2005-07-15 22:45:37 UTC
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)
Comment 41 Pete Zaitcev 2005-07-15 22:48:50 UTC
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.
Comment 42 Peter Wainwright 2005-08-14 12:14:34 UTC
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
Comment 43 Pete Zaitcev 2005-08-14 18:38:16 UTC
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.
Comment 44 Pete Zaitcev 2005-08-18 21:45:44 UTC
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.
Comment 45 Rob Murphy 2005-08-20 13:27:26 UTC
Created attachment 117940 [details] usbmon as per comment 40
Comment 46 Rob Murphy 2005-08-20 13:29:17 UTC
Created attachment 117941 [details] dmesg as per comment 40
Comment 47 Pete Zaitcev 2005-08-21 05:56:19 UTC
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.
Comment 48 Rob Murphy 2005-08-21 12:37:29 UTC
Created attachment 117951 [details] /proc/bus/usb/devices as per comment 44
Comment 49 Pete Zaitcev 2005-08-23 00:32:31 UTC
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.
Comment 50 nicholas manojlovic 2005-08-23 10:50:11 UTC
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.
Comment 51 Pete Zaitcev 2005-08-23 14:12:07 UTC
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).
Comment 53 Pete Zaitcev 2005-08-23 20:57:39 UTC
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 <firstname.lastname@example.org>. + * 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 <email@example.com> */ 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.
Comment 54 Ngo Than 2005-08-24 10:20:54 UTC
*** Bug 132195 has been marked as a duplicate of this bug. ***
Comment 55 Menno Smits 2005-08-24 22:47:15 UTC
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
Comment 56 Pete Zaitcev 2006-04-05 22:43:36 UTC
What is the situation on FC-5? Everything works, no?
Comment 57 David Zeuthen 2006-04-06 02:57:11 UTC
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.
Comment 58 David Andersson 2006-04-08 21:25:52 UTC
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.
Comment 59 Penelope Fudd 2006-05-20 00:25:09 UTC
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
Comment 60 Pete Zaitcev 2006-07-11 23:29:59 UTC
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.
Comment 61 Jeff Pearson 2006-07-12 00:18:49 UTC
Works for me on FC5. Apologies for not watching this discussion more closely earlier.
Comment 62 Pete Zaitcev 2006-07-12 01:43:24 UTC
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.