Bug 154955 - eject command does not make ipod safe for removal
eject command does not make ipod safe for removal
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
: 132195 (view as bug list)
Depends On:
Blocks: FCMETA_USB
  Show dependency treegraph
 
Reported: 2005-04-14 21:57 EDT by Jeff Pearson
Modified: 2007-11-30 17:11 EST (History)
14 users (show)

See Also:
Fixed In Version: FC-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-11 21:43:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
contents of /var/log/messages (3.78 MB, text/plain)
2005-05-25 11:33 EDT, Jeff Pearson
no flags Details
output of /proc/mounts (481 bytes, text/plain)
2005-05-25 11:34 EDT, Jeff Pearson
no flags Details
output of "strace eject /media/ipod" (6.02 KB, text/plain)
2005-05-25 11:34 EDT, Jeff Pearson
no flags Details
dmesg output (18.18 KB, text/plain)
2005-06-24 20:44 EDT, Rob Murphy
no flags Details
strace output (6.10 KB, text/plain)
2005-06-24 20:45 EDT, Rob Murphy
no flags Details
usbmon (4.75 KB, text/plain)
2005-06-24 20:46 EDT, Rob Murphy
no flags Details
strace using eject-2.0.13-15.bz154955.2 (6.09 KB, text/plain)
2005-06-25 17:00 EDT, Robert Brooks
no flags Details
usbmon as per comment 40 (44.30 KB, text/plain)
2005-08-20 09:27 EDT, Rob Murphy
no flags Details
dmesg as per comment 40 (27.31 KB, text/plain)
2005-08-20 09:29 EDT, Rob Murphy
no flags Details
/proc/bus/usb/devices as per comment 44 (2.14 KB, text/plain)
2005-08-21 08:37 EDT, Rob Murphy
no flags Details

  None (edit)
Description Jeff Pearson 2005-04-14 21:57:58 EDT
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-14 22:03:57 EDT
eject won't work whilst its still mounted. You'll need to umount it first.
Comment 2 David Zeuthen 2005-04-14 22:12:02 EDT
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-14 22:27:21 EDT
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-14 22:38:38 EDT
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-14 22:39:36 EDT
Btw, I think this applies to all iPod generations but ICBW.
Comment 6 David Zeuthen 2005-04-14 23:06:28 EDT
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 01:30:51 EDT
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 00:37:29 EDT
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@decompose.build.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]#
Comment 9 David Zeuthen 2005-05-20 13:15:07 EDT
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 19:14:25 EDT
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 11:33:04 EDT
Created attachment 114831 [details]
contents of /var/log/messages

As requested...
Comment 12 Jeff Pearson 2005-05-25 11:34:07 EDT
Created attachment 114832 [details]
output of /proc/mounts

as requested...
Comment 13 Jeff Pearson 2005-05-25 11:34:57 EDT
Created attachment 114833 [details]
output of "strace eject /media/ipod"

as requested...
Comment 14 Pete Zaitcev 2005-06-07 19:54:56 EDT
I'm stunned by the -EIO. No idea how that could have happened...
Comment 15 Menno Smits 2005-06-08 06:31:19 EDT
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 05:01:38 EDT
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 04:55:44 EDT
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 13:16:35 EDT
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 18:03:20 EDT
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@tweety.build.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.
Comment 20 Pete Zaitcev 2005-06-24 17:03:29 EDT
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 19:16:34 EDT
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 19:51:42 EDT
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-24 20:44:01 EDT
Created attachment 115964 [details]
dmesg output

dmesg output
Comment 24 Rob Murphy 2005-06-24 20:45:18 EDT
Created attachment 115965 [details]
strace output

strace output
Comment 25 Rob Murphy 2005-06-24 20:46:58 EDT
Created attachment 115966 [details]
usbmon

usbmon (hope i got this one right...)
Comment 26 Pete Zaitcev 2005-06-24 23:00:11 EDT
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 14:54:22 EDT
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 17:00:46 EDT
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 17:31:39 EDT
Beautiful, now works for me as well.
Comment 30 Pete Zaitcev 2005-06-25 19:24:10 EDT
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-25 20:23:11 EDT
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 14:49:43 EDT
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 16:22:23 EDT
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 16:28:17 EDT
with udevd killed also still not ejecting
Comment 35 Robert Brooks 2005-06-26 19:29:00 EDT
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 19:33:44 EDT
resetting the ipod fixed this, I blame the hardware manufacturer ;-)
Comment 37 Dave Jones 2005-06-27 19:26:51 EDT
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 04:13:56 EDT
still present on fc4
Comment 39 Dave Jones 2005-07-15 17:44:49 EDT
[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 18:45:37 EDT
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 18:48:50 EDT
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 08:14:34 EDT
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 14:38:16 EDT
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 17:45:44 EDT
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 09:27:26 EDT
Created attachment 117940 [details]
usbmon as per comment 40
Comment 46 Rob Murphy 2005-08-20 09:29:17 EDT
Created attachment 117941 [details]
dmesg as per comment 40
Comment 47 Pete Zaitcev 2005-08-21 01:56:19 EDT
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 08:37:29 EDT
Created attachment 117951 [details]
/proc/bus/usb/devices as per comment 44
Comment 49 Pete Zaitcev 2005-08-22 20:32:31 EDT
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 06:50:11 EDT
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 10:12:07 EDT
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 52 Pete Zaitcev 2005-08-23 10:14:01 EDT
See bug 158548 for changes in eject(1).
Comment 53 Pete Zaitcev 2005-08-23 16:57:39 EDT
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@redhat.com>.
+ * 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@argo.co.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.
Comment 54 Ngo Than 2005-08-24 06:20:54 EDT
*** Bug 132195 has been marked as a duplicate of this bug. ***
Comment 55 Menno Smits 2005-08-24 18:47:15 EDT
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 18:43:36 EDT
What is the situation on FC-5? Everything works, no?
Comment 57 David Zeuthen 2006-04-05 22:57:11 EDT
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 17:25:52 EDT
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-19 20:25:09 EDT
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 19:29:59 EDT
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-11 20:18:49 EDT
Works for me on FC5.  Apologies for not watching this discussion more closely
earlier.
Comment 62 Pete Zaitcev 2006-07-11 21:43:24 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.