dell mini 10v SD/SDHC slot gets ejected from the USB bus on nautilus 'eject'

Bug #404185 reported by Andy Whitcroft on 2009-07-24
94
This bug affects 19 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
Medium
Unassigned
gvfs
Fix Released
Medium
obsolete
Fix Released
Medium
glib2.0 (Ubuntu)
Low
Unassigned
Karmic
Low
Unassigned
gvfs (Ubuntu)
High
Martin Pitt
Karmic
High
Martin Pitt
linux (Ubuntu)
Undecided
Unassigned
Karmic
Undecided
Unassigned

Bug Description

The Dell Mini 10v has an internal USB connected SD/SDHC/xxx card reader device. When a card is introduced it appears as expected displaying with the normal eject icon in Nautilus. When this is clicked the filesystem is unmounted and /dev/sdb is ejected. This leads to the card reader being removed from the USB bus and is no longer available. Removing and introducing cards has no effect. If you simply unmount the card it seems to work as expected, you can remove and reintroduce the card and it gets remounted.

I am unsure how Nautilus decides whether it should use Eject but it likley needs quirking for this device.

ProblemType: Bug
Architecture: i386
Date: Fri Jul 24 16:42:02 2009
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=80825280-6e78-4857-88fb-8041ab4c3480
MachineType: Dell Inc. Inspiron 1011
NonfreeKernelModules: wl
Package: linux-generic 2.6.31.3.14
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-4-generic root=UUID=5fdffa9d-a806-4009-930a-bf637c8f5cfa ro quiet splash
ProcEnviron:
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-4.21-generic
RelatedPackageVersions:

SourcePackage: linux-meta
Uname: Linux 2.6.31-4-generic i686
dmi.bios.date: 07/06/2009
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A05
dmi.board.name: CN0Y53
dmi.board.vendor: Dell Inc.
dmi.board.version: A05
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A05
dmi.modalias: dmi:bvnDellInc.:bvrA05:bd07/06/2009:svnDellInc.:pnInspiron1011:pvrA05:rvnDellInc.:rnCN0Y53:rvrA05:cvnDellInc.:ct8:cvrA05:
dmi.product.name: Inspiron 1011
dmi.product.version: A05
dmi.sys.vendor: Dell Inc.

Andy Whitcroft (apw) wrote :
affects: linux-meta (Ubuntu) → linux (Ubuntu)
Mario Limonciello (superm1) wrote :

So it looks like nautilus looks at a combination of

g_drive_can_eject | g_volume_can_eject | g_mount_can_eject

to determine if eject is shown.

http://library.gnome.org/devel/gio/stable/GDrive.html#g-drive-can-eject
http://library.gnome.org/devel/gio/unstable/GVolume.html#g-volume-can-eject
http://library.gnome.org/devel/gio/2.15/GMount.html#g-mount-can-eject

So either the kernel needs to supply a quirk, or gio needs a quirk.

affects: nautilus (Ubuntu) → glib2.0 (Ubuntu)
Sebastien Bacher (seb128) wrote :

why do you think that gio needs a "quirk"?

Changed in glib2.0 (Ubuntu):
importance: Undecided → Low
status: New → Incomplete

You can't physically eject this hardware. Its hardwired into the
system. So if you send an eject command, the only way to get it back
is a usb reset or reboot the system. So nautilis should only offer to
unmount.

On 07/27/2009, Sebastien Bacher <email address hidden> wrote:
> why do you think that gio needs a "quirk"?
>
> ** Changed in: glib2.0 (Ubuntu)
> Importance: Undecided => Low
>
> ** Changed in: glib2.0 (Ubuntu)
> Status: New => Incomplete
>
> --
> dell mini 10v SD/SDHC slot gets ejected from the USB bus on nautilus 'eject'
> https://bugs.launchpad.net/bugs/404185
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Sent from my mobile device

Mario Limonciello
<email address hidden>

Sebastien Bacher (seb128) wrote :

the bug on http://bugzilla.gnome.org/show_bug.cgi?id=576587 suggest that eject is used in a consistant way and on non ejectable devices too

Stuart Read (sread) wrote :

Based on information I came across on the MyDellMini forum, I think the card reader is not actually on the USB bus. Maybe PCI, PCMIA or something? I am also seeing this bug as of August.
Is there anything else I can do to contribute to this bug?

Changed in glib2.0 (Ubuntu):
assignee: nobody → Canonical Ubuntu QA Team (canonical-qa)
Jerone Young (jerone) wrote :

The device is a Realtek Mass Storage Device and it is connected via USB. I've posted more extensive lsusb info on it.

Jerone Young (jerone) wrote :

Another observation is if I use the "eject" command on the comand line the Realtek device does get ejected from the USB bus. Only when you eject from nautilus does it do it.

Jerone Young (jerone) wrote :

This definitely seems to only be happing with Nautilus & gvfs. I believe this patch is the culprit if it made it in :

http://cgit.freedesktop.org/~david/gvfs/commit/?h=gdu-volume-monitor&id=303cfd43578f0a4198c063f1a5fbcd16fec2b0bf

When using other programs such as Palimpsest (it's the new disk utility) .. it will eject the volume from the Realtek reader without issue and it still stays connected to the USB bus.

Also this bug is interesting:
http://bugzilla.gnome.org/show_bug.cgi?id=574067

Jerone Young (jerone) wrote :

So reverting the patch pointed to above does resolve the issue.

This patch needs better logic added to it. I assume this problem will also effect other Dell & other vendor machines with SD card readers.

Changed in gvfs (Ubuntu):
status: New → Confirmed
Changed in linux (Ubuntu):
status: New → Invalid
Changed in glib2.0 (Ubuntu):
status: Incomplete → Invalid
Jerone Young (jerone) wrote :

I'm posting a tarball with compiled packages with the reverted patch. This will allow for quick testing for folks.

Jerone Young (jerone) wrote :

To add another thing. With the reverted patch the card reader will be removed from the usb bus on eject. But once you remove the SD card and place it back in it shows back up and works as it should.

I believe this is the same behavior it does with Ubuntu 9.04 also.

Jerone Young (jerone) wrote :

I have a pci express SD card reader. This issue effects it also. When gvfs does the eject the reader is unusable until you physically eject and then reinsert it.

I'm getting a hold of a Kindle & a ipod to see if a better solution can be found at gvfs layer then what the patch I specified above is now doing.

Martin Pitt (pitti) wrote :

There were good reasons to offer both Eject and Unmount in the menu, and it was discussed several times upstream.

However, the real bug here seems that choosing eject with that device does not merely eject the medium, but disconnects the entire drive, right?

Changed in gvfs (Ubuntu):
importance: Undecided → Low
status: Confirmed → Triaged
Kai Jauch (kaijauch) wrote :

Correct. My USB card reader is also affected. After ejecting, the power led turns off and I have to reconnect the device in order to be able to use it again.

Bus 001 Device 014: ID 058f:6362 Alcor Micro Corp. Hi-Speed 21-in-1 Flash Card Reader/Writer (Internal/External)

Attaching kernel log from plugging the card reader in, inserting a SD card and hitting eject in nautilus. The kernel doesn't seem to notice that the reader powered down after ejecting.

Kai Jauch (kaijauch) wrote :
Kai Jauch (kaijauch) wrote :
Kai Jauch (kaijauch) wrote :

Gnah, ignore the first lsusb_before_eject.txt. This is the right one.

Jerone Young (jerone) wrote :

@Kai,

       Yes it affects any storage device attached via USB. It's worst on Desktops and laptops with usb storage devices integrated.

We are working to figure out a better solution for this patch made to gvfs here:
http://cgit.freedesktop.org/~david/gvfs/commit/?h=gdu-volume-monitor&id=303cfd43578f0a4198c063f1a5fbcd16fec2b0bf

While it allows your ipod & kindle to display that they are safe to remove. It ends up causing massive regression on usb storage devices.

Changed in oem-priority:
importance: Undecided → Medium
Changed in oem-priority:
status: New → Triaged
assignee: nobody → Canonical Ubuntu QA Team (canonical-qa)
Changed in glib2.0 (Ubuntu):
assignee: Canonical Ubuntu QA Team (canonical-qa) → nobody
Martin Pitt (pitti) wrote :

I think the "does get" was a typo here:

  "Another observation is if I use the "eject" command on the comand line the Realtek device does get ejected from the USB bus. Only when you eject from nautilus does it do it."

and should mean "with using /usr/bin/eject the underlying reader does _not_ get ejected.

It seems that dk-disks somehow ejects the devices "too deeply".

affects: gvfs (Ubuntu) → devicekit-disks (Ubuntu)
Changed in devicekit-disks (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
Jerone Young (jerone) wrote :

@Martin
     Thank for fixing up the typos. But this issue is at the gvfs level from what I've determined. Here is the exact patch in the repository that is causing all these issues:

http://git.gnome.org/cgit/gvfs/commit/?id=b8f430b51f4071a7c7ba6601caf20f817fda531d

   It basically moves logic that was in HAL and now forcing all usb storage devices to be ejected from the USB bus. It's mainly for iPod & Kindle & is not needed for any other devices. Just causes regressions. If you try the packages I compiled removing the patch the problem goes away.

   Also the user interface regression with Nautilus as this is unexpected behavior from how Nautilus has behaved in the past.

Jerone Young (jerone) wrote :

@Martin
      The problem isn't to offer both eject & umount. The problem is that when you click the eject button in Nautilus. It completely disconnects the device. The patch above force fully makes all usb storage devices get disconnected from the USB bus. Meaning you can't use them again.

       There is no problem though using programs like palimpsest (the Gnome disk utility tool) which use device kit and don't have this issue.

Jerone Young [2009-09-07 20:26 -0000]:
> @Martin
> The problem isn't to offer both eject & umount.

Right, that's why gvfs wouldn't need to be changed.

> The problem is that when you click the eject button in Nautilus. It
> completely disconnects the device.

Exactly. As far as I can see, devkit-disks should be a little less
aggresive and just do what /usr/bin/eject does, since you said that
this works.

Joey Stanford (joey) wrote :

Targeted per oem-priority meeting to karmic-updates. Kevin K. to chat with Martin P. about this bug.

Changed in devicekit-disks (Ubuntu):
milestone: none → karmic-updates

Martin, I believe this is important for customers. Is there any chance we can get this fixed for Karmic? If the answer is no, please remove the milestone and set the priority as appropriate. Thank you for consideration in any case.

Changed in devicekit-disks (Ubuntu Karmic):
milestone: karmic-updates → ubuntu-9.10
importance: Low → Medium
Martin Pitt (pitti) wrote :

Rick Spencer [2009-09-28 20:18 -0000]:
> Martin, I believe this is important for customers. Is there any chance
> we can get this fixed for Karmic?

Yes, it's on my list of post-beta stuff to look at.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Note that this is a Medium priority bug in the post-beta time period. As such, please expect that this bug may not get fixed for final release, as Critical and High bugs will take precedence.

Changed in devicekit-disks (Ubuntu Karmic):
importance: Medium → High

Some laptops like the Dell Mini 10 have builtin SD card readers which are wired through an internal USB bus. The current behaviour is that if you click the eject button in nautilus, the card reader device gets ejected and disconnected, and cannot be reactivated ever, except by a reboot.

The cause of this is that DK-d's update_info_drive() sets "can_detach" for all USB devices currently, which causes devkit-disks-helper-drive-detach to be called on them.

So clearly this is too eager. Obviously there is no way to programmatically tell whether a particular USB device can actually be physically detached or whether it's sitting inside a case. So I see the following options right now:

 * If we can tell whether the device has removable media (like card readers), don't detach the reader device. Otherwise, continue to set can_detach. This still errs on the side of breakage, but at least would fix the behaviour with those card readers. I'm currently not sure whether this is feasible, I asked the original reporter for a dk-disks dump to check the properties.

 * Don't set can_detach for all USB devices, and just add udev rules which set ID_DRIVE_DETACHABLE for some known safe cases.

  This would again introduce a whitelist, something which we hoped to get rid of with https://bugzilla.gnome.org/show_bug.cgi?id=576587.

So my question is, why was this current can_detach behaviour introduced? Are there some devices where not even eject is enough? Years ago, when I tested this with an iPod, umount wasn't sufficient, but eject made the "unsafe to remove blabla" warning go away.

(In reply to comment #0)
> Some laptops like the Dell Mini 10 have builtin SD card readers which are wired
> through an internal USB bus. The current behaviour is that if you click the
> eject button in nautilus, the card reader device gets ejected and disconnected,
> and cannot be reactivated ever, except by a reboot.

Huh, that's interesting, I never thought of that problem ;-).

(Also, the fact that Dell is so cheap that they use USB-connected SD readers is interesting in it's own right.)

> The cause of this is that DK-d's update_info_drive() sets "can_detach" for all
> USB devices currently, which causes devkit-disks-helper-drive-detach to be
> called on them.
>
> So clearly this is too eager. Obviously there is no way to programmatically
> tell whether a particular USB device can actually be physically detached or
> whether it's sitting inside a case. So I see the following options right now:
>
> * If we can tell whether the device has removable media (like card readers),
> don't detach the reader device. Otherwise, continue to set can_detach. This
> still errs on the side of breakage, but at least would fix the behaviour with
> those card readers. I'm currently not sure whether this is feasible, I asked
> the original reporter for a dk-disks dump to check the properties.
>
> * Don't set can_detach for all USB devices, and just add udev rules which set
> ID_DRIVE_DETACHABLE for some known safe cases.
>
> This would again introduce a whitelist, something which we hoped to get rid
> of with https://bugzilla.gnome.org/show_bug.cgi?id=576587.
>
> So my question is, why was this current can_detach behaviour introduced? Are
> there some devices where not even eject is enough? Years ago, when I tested
> this with an iPod, umount wasn't sufficient, but eject made the "unsafe to
> remove blabla" warning go away.

The different between DriveEject() and DriveDetach() is that the latter makes the whole device go away while the former only makes partitions go away. DriveEject() is sufficient on iPod and Kindle to make the "unsafe to remove blabla" warning go away.

Maybe we can look at the usb interface classes to avoid ejecting USB connected card readers? I also think the DMI data tells you whether a particular usb port has an external receptable - I remember Kay talking about that (adding to Cc).

If this works for the Dell Mini maybe we can use this and vendors who are not properly populating DMI data will suffer (and we'd quirk this up via udev rules).

I don't know. Please also ask the original reporter for output of dmidecode and 'tree /sys'. Thanks.

(In reply to comment #1)

> DriveEject() is sufficient on iPod and Kindle to make the "unsafe to remove
> blabla" warning go away.

Right, that's why I wondered why drive detaching was necessary. Just as a way to "clean up" and also reduce power consumption, or whether some devices really need it. (Just in case we need to disable can_detach right before a release, when time gets tight :) ).

> Maybe we can look at the usb interface classes to avoid ejecting USB connected
> card readers? I also think the DMI data tells you whether a particular usb port
> has an external receptable - I remember Kay talking about that (adding to Cc).

That would be nice. The original report already has an udev dump (http://launchpadlibrarian.net/29486956/UdevDb.txt):

P: /devices/pci0000:00/0000:00:1d.7/usb1/1-3/1-3:1.0/host2/target2:0:0/2:0:0:0/block/sdb
E: ID_VENDOR=Generic-
E: ID_VENDOR_ENC=Generic-
E: ID_VENDOR_ID=0bda
E: ID_MODEL=Multi-Card
E: ID_MODEL_ENC=Multi-Card\x20\x20\x20\x20\x20\x20
E: ID_MODEL_ID=0158
E: ID_TYPE=disk
E: ID_INSTANCE=0:0
E: ID_BUS=usb
E: ID_USB_INTERFACES=:080650:

> Please also ask the original reporter for output of dmidecode and
> 'tree /sys'.

Done, will report back when data arrives.

Thanks!

> E: ID_USB_INTERFACES=:080650:

So class 08 is just "mass storage". According to http://www.usb.org/developers/devclass_docs/usb_msc_overview_1.2.pdf, subclass 06 is "SCSI transparent command set" (very helpful :-( ) and protocol 50 is "Bulk-only transport". So nothing specific for card readers here, I'm afraid. My USB stick is exactly the same.

(In reply to comment #2)
> (In reply to comment #1)
>
> > DriveEject() is sufficient on iPod and Kindle to make the "unsafe to remove
> > blabla" warning go away.
>
> Right, that's why I wondered why drive detaching was necessary. Just as a way
> to "clean up" and also reduce power consumption, or whether some devices really
> need it. (Just in case we need to disable can_detach right before a release,
> when time gets tight :) ).

Yeah. Btw, It turns out Windows actually powers down the port for this thing - I asked Alan Stern for a similar mechanism in Linux. See

http://thread.gmane.org/gmane.linux.usb.general/22706

>
> > Maybe we can look at the usb interface classes to avoid ejecting USB connected
> > card readers? I also think the DMI data tells you whether a particular usb port
> > has an external receptable - I remember Kay talking about that (adding to Cc).
>
> That would be nice.

I wonder how it works on Windows - e.g. is the SD Reader included in the "Safely Remove Hardware" list? And if so, does it require a reboot if you safely remove the device?

If not, is this because of a .inf file (moral equivalent to udev rules - at least insofar that these files are used for quirks too) or do they parse the DMI data?

> > Please also ask the original reporter for output of dmidecode and
> > 'tree /sys'.
>
> Done, will report back when data arrives.

Cool. We might end up needing to blacklist devices if the DMI data isn't helpful. I'd really like us to avoid that...

Alternatively we can stop doing DriveDetach() automatically when the user selects Eject from the file manager menu (or presses the eject icon in the file manager siderbar).. and instead always offer a "Safely Remove Hardware" menu item. That would be a step back user-experience-wise though...

Martin Pitt (pitti) wrote :

I think I know what's going on here, but I'd appreciate if you could confirm a few issues.

You say

> When using other programs such as Palimpsest (it's the new disk utility) .. it will eject the volume from the Realtek reader without issue and it still stays connected to the USB bus.

There are actually three different concepts in palimpsest:

 * If you select a partition of a device, you have the "unmount" button (second button in toolbar, with the two blue arrows). This doesn't do any ejecting, and is unproblematic.

 * If you select the device containing the partitions, there are two buttons: One "eject medium" (third in the toolbar) with a CD eject symbol (arrow with bar), which calls "eject /dev/sdb"; and one "remove device from system and power off" (fourth in the toolbar) with a "stop" symbol (red square) which calls devkit-disks-helper-drive-detach.

I assume that when you wrote the above, you used the third button (eject), not the fourth one (remove device from system). Can you confirm?

I assume that devkit-disks-helper-drive-detach is the one which causes the grief here, and that merely calling "eject" does not cause the irrevocable USB bus disconnect (you also said so in a comment). So please confirm again that calling "sudo eject /dev/sdb" works fine.

So we shouldn't detach the drive from nautilus, at least not unconditionally as we do right now. A compromise might be to not detach drives which can hold removable media. I'll discuss that with David.

Can you please do

  devkit-disks --dump > /tmp/dk-disks.txt

with the SD card being inserted and mounted, and attach /tmp/dk-disks.txt here? I'd like to know the particular properties of this reader.

Thanks!

Martin Pitt (pitti) wrote :

Note to self: The cleanest way to fix this is in ./src/devkit-disks-device.c, update_info_drive(). Right now it sets "can_detach" for all USB devices.

Martin Pitt (pitti) wrote :

I forwarded the bug upstream and will discuss the proper solution with David.

But for the record, if a proper solution doesn't land in time, I now know how to trivially fix this bug for karmic. If nothing else helps, we can just disable "can_detach" completely, to pretty much get back the behaviour from Jaunty. However, first I want to get a deeper understanding why this was introduced in the first place.

Changed in devicekit:
status: Unknown → Confirmed

Richard, I was told you have hardware like this - any chance you can attach the output of dmidecode? And if you have Windows, any chance you can try out the thing I mentioned in comment 4? Thanks.

Martin Pitt (pitti) wrote :

Please also do

  sudo dmidecode > /tmp/dmi.txt
  ls -lR /sys |gzip -9 > /tmp/sys.txt.gz

and attach /tmp/dmi.txt and /tmp/sys.txt.gz

Thanks!

Changed in devicekit-disks (Ubuntu Karmic):
status: Triaged → Incomplete
Stuart Read (sread) wrote :

Here are the requested files.
-Stuart

Stuart Read (sread) wrote :
Stuart Read (sread) wrote :
Stuart Read (sread) wrote :

Also:
I can confirm that sudo eject /dev/sdb works as expected.
With palimpsest, unmounting the partition and then using the _third_ "eject" button works.
However, unmounting the partition and the using the _fourth_ "Detach device from system and power off" button, results in exactly that happening and the device won't return until reboot (as happens when you press the button in Nautilus).
-Stuart

Created an attachment (id=30134)
dmidecode output

Output of dmidecode. I'm not a guru with reading those, but it does not seem very useful to me. :-( There is no reference to "SD" or "card" or "storage", and just one USB related record which doesn't even say it's internal (well, the thing does have external USBs as well):

Handle 0x0008, DMI type 8, 9 bytes
Port Connector Information
        Internal Reference Designator: USB
        Internal Connector Type: None
        External Reference Designator: Not Specified
        External Connector Type: Access Bus (USB)
        Port Type: USB

http://launchpadlibrarian.net/33181405/sys.txt.gz has an ls -lR /sys, http://launchpadlibrarian.net/33181491/dk-disks.txt is the devkit-disks --dump output.

The dk-d dump looks pretty much identical to an USB stick (they even both falsely claim "rotational media: 1" :-) ) except for the product name. So if nothing else helps, we could match on product == "*Card" to fix it for this particular model, but this does not seem to be very robust to me.

I'll ask the original reporter about trying Windows.

(In reply to comment #5)
> Richard, I was told you have hardware like this - any chance you can attach the
> output of dmidecode? And if you have Windows, any chance you can try out the
> thing I mentioned in comment 4? Thanks.

I don't have Windows on it, sorry. I've got a copy of Windows XP home I could install on it if you wish, but it would mean nuking my current F11 install. I can do this if you really need the data.

Martin Pitt (pitti) wrote :

Thanks a lot, Stuart! I forwarded the information upstream. Unfortunately it does not seem that dmidecode gives us any clue that this particular USB port is internal only.

David had another question:

> It turns out Windows actually powers down the port for this thing -I asked Alan Stern for a similar mechanism in Linux. See
> http://thread.gmane.org/gmane.linux.usb.general/22706
> I wonder how it works on Windows - e.g. is the SD Reader included in the "Safely Remove Hardware" list? And if so, does it require a reboot if you safely remove the device?
> If not, is this because of a .inf file (moral equivalent to udev rules - at least insofar that these files are used for quirks too) or do they parse the DMI data?

Do you happen to have Windows on this machine as well? If so, would be great if you could test this. If not, don't bother.

Changed in devicekit:
status: Confirmed → In Progress

(In reply to comment #8)
> (In reply to comment #5)
> > Richard, I was told you have hardware like this - any chance you can attach the
> > output of dmidecode? And if you have Windows, any chance you can try out the
> > thing I mentioned in comment 4? Thanks.
>
> I don't have Windows on it, sorry. I've got a copy of Windows XP home I could
> install on it if you wish, but it would mean nuking my current F11 install. I
> can do this if you really need the data.

That's OK, no need to do this - I'm pretty sure they just use an .inf file. Thanks anyway.

Download full text (3.3 KiB)

(In reply to comment #6)
> Created an attachment (id=30134) [details]
> dmidecode output
>
> Output of dmidecode. I'm not a guru with reading those, but it does not seem
> very useful to me. :-( There is no reference to "SD" or "card" or "storage",
> and just one USB related record which doesn't even say it's internal (well, the
> thing does have external USBs as well):
>
> Handle 0x0008, DMI type 8, 9 bytes
> Port Connector Information
> Internal Reference Designator: USB
> Internal Connector Type: None
> External Reference Designator: Not Specified
> External Connector Type: Access Bus (USB)
> Port Type: USB

Just for the record, see [0] from one of my boxes at home.

Of course, I have no idea how to map USB0, USB1 to actual USB host controllers or even ports on the same host controller. It might be possible to get the kernel USB drivers to parse/interpret DMI data and then export some attributes like whether the actual USB port is external or internal.

But that's going to be a lot of work. And it might be imprecise because vendors don't properly populate DMI. And there's no guarantee the USB kernel folks are interested in this.

[0] :

Handle 0x0010, DMI type 8, 9 bytes
Port Connector Information
        Internal Reference Designator: USB0
        Internal Connector Type: None
        External Reference Designator: USB0
        External Connector Type: Access Bus (USB)
        Port Type: USB

Handle 0x0011, DMI type 8, 9 bytes
Port Connector Information
        Internal Reference Designator: USB1
        Internal Connector Type: None
        External Reference Designator: USB1
        External Connector Type: Access Bus (USB)
        Port Type: USB

Handle 0x0012, DMI type 8, 9 bytes
Port Connector Information
        Internal Reference Designator: USB2
        Internal Connector Type: None
        External Reference Designator: USB2
        External Connector Type: Access Bus (USB)
        Port Type: USB

Handle 0x0013, DMI type 8, 9 bytes
Port Connector Information
        Internal Reference Designator: USB3
        Internal Connector Type: None
        External Reference Designator: USB3
        External Connector Type: Access Bus (USB)
        Port Type: USB

[...]

Handle 0x0030, DMI type 8, 9 bytes
Port Connector Information
        Internal Reference Designator: JUSR2 - USB4/5
        Internal Connector Type: Other
        External Reference Designator: Not Specified
        External Connector Type: None
        Port Type: USB

Handle 0x0031, DMI type 8, 9 bytes
Port Connector Information
        Internal Reference Designator: JUSR3 - USB6/7
        Internal Connector Type: Other
        External Reference Designator: Not Specified
        External Connector Type: None
        Port Type: USB

Handle 0x0032, DMI type 8, 9 bytes
Port Connector Information
        Internal Reference Designator: USB8 - USB8
        Internal Connector Type: Access Bus (USB)
        External Reference Designator: Not Specified
        External Connector Type: None
        Port Type: USB

Handle 0x0033, DMI type 8, 9 bytes
Port Connector Information
        Internal Reference Designator: USB9 - USB9
        Inter...

Read more...

So, based on all this I think the only viable approach is to

1. Add a note to the docs DriveDetach() saying that the drive, while
   detachable, may be located inside the box. E.g. basically recommend
   that policy agents only call DriveDetach() when the user specifically
   asked to "Safely Remove Hardware"

2. Fix up GVfs/Nautilus so we never call DriveDetach() when the user presses
   the "Eject" button - e.g. only when the user chooses the "Safely Remove
   Hardware", we call DriveDetach().

3. In the future we could add a DriveIsOnExternalPort boolean property that
   is set to TRUE if, and only if, we are 100% the port is external.

Thoughts?

Martin Pitt (pitti) on 2009-10-08
Changed in devicekit-disks (Ubuntu Karmic):
status: Incomplete → Triaged

Filed the GVfs bug with a patch

https://bugzilla.gnome.org/show_bug.cgi?id=597864

and committed the patch to master and gnome-2-28. It should be in the next GVfs point release for GNOME 2.28. Martin, if you can check the patch works as expect it would be great. Thanks.

I'm keeping this bug open until the docs for DriveDetach() are amended.

> Martin, if you can check the patch works as expect it would be great.

It does seem to do the right thing here, thanks! I'll also ask the original reporters to triple-check.

Martin Pitt (pitti) wrote :

Discussed with David, and we decided that eventually we want to have the current behaviour, but only once we can reliably detect through DMI data that a port is external. For now we disable the detaching for the "eject" button/menu option and instead offer "savely remove drive" in the context menu (for devices that really need it). Slightly worse user experience, but safe.

http://git.gnome.org/cgit/gvfs/commit/?id=6e70902ee77cb0bd6063bcf4d215b13a13bf5ee4

affects: devicekit-disks (Ubuntu Karmic) → gvfs (Ubuntu Karmic)
Changed in gvfs (Ubuntu Karmic):
status: Triaged → In Progress

Fixing up Summary for posterity

Changed in devicekit:
status: In Progress → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gvfs - 1.4.0-0ubuntu2

---------------
gvfs (1.4.0-0ubuntu2) karmic; urgency=low

  * Add 00git-separate-eject-detach.patch: Some systems use internal USB
    devices. Automatically detaching such drives when calling
    gdu_drive_eject() (triggered by e.g. the eject button in the Nautilus
    sidebar) as we do right now leads to loss of the drive until reboot (since
    the device is internal). The only viable option right now is to separate
    "Safely Remove Drive" and "Eject".
    If we gain infrastructure to let us know with 100% accuracy that a
    given receptacle is external we can go back to the previous behavior.
    (LP: #404185)

 -- Martin Pitt <email address hidden> Fri, 09 Oct 2009 08:35:05 +0200

Changed in gvfs (Ubuntu Karmic):
status: In Progress → Fix Released
Changed in oem-priority:
assignee: Canonical Ubuntu QA Team (canonical-qa) → nobody
Jerone Young (jerone) wrote :

Verified. Fix is working. No longer ejects internal card reader from bus.

Changed in oem-priority:
status: Triaged → Fix Released

Hey,

I was just looking through the USB2 spec and stumbled upon section 11.23.2.1 - the DeviceRemovable descriptor. Seems to work for, at least, my IBM UltraNav keyboard [0] - see [1] for lsusb snippets.

Can anyone with access to a Dell Mini (Richard?) please attach 'lsusb -vvv' and 'lsusb -t' output? Many thanks!

If it checks out for the Dell Mini, we should be able to figure out whether a given USB device really is removable or not (could be incorporated as a patch to udev's usb_id).

     David

[0] : http://www.geek.com/articles/chips/review-lenovo-thinkpad-ultranav-keyboard-20090325/

[1] :
lsusb -t:
[...]
    |-Dev# 3 Vendor 0x04b3 Product 0x3016
    | |-Dev# 5 Vendor 0x04b3 Product 0x3018
    | `-Dev# 6 Vendor 0x06cb Product 0x0009
[...]

lsusb -vvv:

[...]
Hub Descriptor:
  bLength 9
  bDescriptorType 41
  nNbrPorts 4
  wHubCharacteristic 0x0009
    Per-port power switching
    Per-port overcurrent protection
  bPwrOn2PwrGood 50 * 2 milli seconds
  bHubContrCurrent 100 milli Ampere
  DeviceRemovable 0x18
  PortPwrCtrlMask 0xff
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power
   Port 3: 0000.0303 lowspeed power enable connect
   Port 4: 0000.0303 lowspeed power enable connect
[...]

Oh, nice! I asked the original reporters for their data, too.

Created an attachment (id=30793)
lsusb -t

(In reply to comment #16)
> Can anyone with access to a Dell Mini (Richard?) please attach 'lsusb -vvv' and
> 'lsusb -t' output? Many thanks!

Created an attachment (id=30794)
sudo lsusb -vvv

http://launchpadlibrarian.net/34592147/usb.txt is the output from Dell mini 10v. Unfortunately all 5 "Hub Descriptor"s have "DeviceRemovable 0x00"..

Martin Pitt (pitti) wrote :

In order to fix this in a nicer manner in the future, can you please do

  lsusb -vvv > /tmp/usb.txt

and attach this here? I'm particularly interested in the "DeviceRemovable" descriptor of those card reader USB ports.

Thank you!

Hey, thanks for the output. Now that we know there is a mechanism for conveying this data, I'm tempted to

 1. Make udev's usb_id set a ID_USB_HOTPLUGGABLE property by analyzing
    the hub descriptors. Then take this property into account when
    calculating the CanDetach property.

 2. Fix/quirk broken hardware like the Dell Mini with simple udev rules
    that can override ID_USB_HOTPLUGGABLE.

    Also notify Dell (and others) of this problem so it won't happen
    in the future.

  • usb.txt Edit (33.1 KiB, text/plain; charset=us-ascii)

lsusb -vvv attached.

-apw

Changed in devicekit:
importance: Unknown → Medium
Changed in gvfs:
importance: Unknown → Medium
status: Unknown → Fix Released
Changed in devicekit:
importance: Medium → Unknown
Changed in devicekit:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.