I was just playing around with this again.  I ran gvfs-gphoto2-volume-monitor from the command line and plugged in the device.  I got these errors:

libhal.c 801 : invalid paramater. *set is NULL.
libhal.c 686 : invalid paramater. *set is NULL.

I hope that gives some kind of clue.

Well I think I have a related issue which I don't know if can be considered the same bug. The difference for me is that mounting my device using gphoto 2 works. However it seems a bit unstable and I also would prefer to have it mounted as mass storage device, which always worked well. With gphoto2 I had some errors when copying files to the device. 

I don't see any reason to mount a device in nautilus using gphoto2 if it is capable to be used as mass storage device.

I also confirm this problem. My player is a Sansa Express 1GB with an 8GB micro SDHC card plugged into. I have two updated Ubuntu boxes: an Intrepid desktop and a Jaunt HP Mini-9 laptop. The former can mount and access without troubles the two volumes (the 1GB internal and the 8GB card), but the last can't even mount only the card. Follow is its dmesg:

[ 3269.668134] usb 1-1: new high speed USB device using ehci_hcd and address 6
[ 3269.803335] usb 1-1: configuration #1 chosen from 1 choice
[ 3269.814824] scsi3 : SCSI emulation for USB Mass Storage devices
[ 3269.816721] usb-storage: device found at 6
[ 3269.816736] usb-storage: waiting for device to settle before scanning
[ 3271.532290] usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd gvfs-gphoto2-vo rqt 192 rq 1 len 1000 ret -110
[ 3272.553303] usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd gvfs-gphoto2-vo rqt 128 rq 6 len 1000 ret -110
[ 3272.654302] usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd gvfs-gphoto2-vo rqt 128 rq 6 len 1000 ret -71
[ 3274.821305] usb-storage: device scan complete
[ 3275.418657] scsi 3:0:0:0: Direct-Access Sandisk Sansa Express 0100 PQ: 0 ANSI: 4
[ 3275.423715] sd 3:0:0:0: [sdc] 1997307 512-byte hardware sectors: (1.02 GB/975 MiB)
[ 3275.425067] sd 3:0:0:0: [sdc] Write Protect is off
[ 3275.425086] sd 3:0:0:0: [sdc] Mode Sense: 3e 00 00 00
[ 3275.425100] sd 3:0:0:0: [sdc] Assuming drive cache: write through
[ 3275.427035] sd 3:0:0:0: [sdc] 1997307 512-byte hardware sectors: (1.02 GB/975 MiB)
[ 3275.427648] sd 3:0:0:0: [sdc] Write Protect is off
[ 3275.427661] sd 3:0:0:0: [sdc] Mode Sense: 3e 00 00 00
[ 3275.427671] sd 3:0:0:0: [sdc] Assuming drive cache: write through
[ 3275.427689] sdc: sdc1
[ 3275.441318] sd 3:0:0:0: [sdc] Attached SCSI removable disk
[ 3275.441665] sd 3:0:0:0: Attached scsi generic sg2 type 0

I can mount and access the SDHC card with a USB card reader adapter in both computers.

Doing the kill I could also have the card mounted and accessable by Nautilus.

I mean, the laptop is a DELL Mini 9 (Mini 910 model). Sorry by the mistake.  ;-)

I have installed Karmic beta and am no longer having this issue.

Still having the issue in Ubuntu 9.10 (Karmic). Killing g-g-v-m enables me to auto-mount my Sansa Fuze 4GB.

Relevant dmesg snip (with g-g-v-m running):

[  428.510050] usb 1-1: new high speed USB device using ehci_hcd and address 9
[  429.760284] hub 1-0:1.0: unable to enumerate USB device on port 1
[  430.301295] usb 2-1: new full speed USB device using ohci_hcd and address 6
[  430.516403] usb 2-1: not running at top speed; connect to a high speed hub
[  430.540570] usb 2-1: configuration #1 chosen from 1 choice
[  430.561086] scsi11 : SCSI emulation for USB Mass Storage devices
[  430.565868] usb-storage: device found at 6
[  430.565875] usb-storage: waiting for device to settle before scanning
[  435.562896] usb-storage: device scan complete
[  457.191280] usb 2-1: reset full speed USB device using ohci_hcd and address 6
[  458.130037] usb 2-1: reset full speed USB device using ohci_hcd and address 6
[  464.780036] usb 2-1: reset full speed USB device using ohci_hcd and address 6
[  465.490037] usb 2-1: reset full speed USB device using ohci_hcd and address 6
[  466.241324] usb 2-1: reset full speed USB device using ohci_hcd and address 6
[  466.762110] scsi 11:0:0:0: Device offlined - not ready after error recovery

Actually neither I nor the original reporter can reproduce this anymore, so maybe something else fixed it.

Created attachment 165819 [details]
dmesg + lsusb, failing case

Created attachment 165821 [details]
dmesg + lsusb, working case (after workaround)

Sorry to spoil the party, looks like I'm suffering from the exact symptoms with my Sansa Express (1 GB + 2 GB) on an up-to-date Ubuntu 10.04. Even the workarond - killing gvfs-gphoto2-volume-monitor - still works for me (thanks for that, btw).

Can be reproduced on an older Pentium IV system and on my Asus netbook as well.

See the two previous attachments for details.

Regards,
   Heinz

https://bugs.freedesktop.org/show_bug.cgi?id=29030 might be the same problem - and https://bugs.freedesktop.org/show_bug.cgi?id=29030#c13 might suggest the bug-fix (which need to be done in the udev rules supplied by gphoto2)

After some more discussion, it seems that the cause is not with the udev rules, but the interaction between gvfs calling libgphoto2.

On my setup, I wrote a simple rule which sets the ID_GPHOTO2 to "0."  After hotplugging the device, it's *still* getting caught up on the gvfs call.  However, as described above, after killing the gvfs-gphoto2 process and forcing permissions to prevent it from re-spawning, my device pops up instantly in nautilus and is perfectly usable.

So, I'm not sure what else to try, or even a suitable work-around.  It seems using udev rules to force gvfs to ignore the ID_GPHOTO rule falsely labeled in libgphoto's rules is not enough to make this device usable.

I think these two things

 1. we should use

     g_udev_device_get_property_as_boolean (d, "ID_GPHOTO2")

    instead of

     g_udev_device_has_property (d, "ID_GPHOTO2")

    in ggphoto2volumemonitor.c. This will at least allow people
    to use custom udev rules to turn of gvfs-gphoto2 handling for
    a device

 2. If the device is a USB device with a single Mass Storage
    interface (e.g. class 8) and it has ID_GPHOTO=2 then ignore
    it as well. That allows us to work around buggy libgphoto2
    udev rules tagging ID_GPHOTO2=1 for devices that we clearly
    don't want to use libgphoto2 for.

will fix the bug and prevent future bugs of this type.

Hi David,


>  1. we should use
> 
>      g_udev_device_get_property_as_boolean (d, "ID_GPHOTO2")
> 
>     instead of
> 
>      g_udev_device_has_property (d, "ID_GPHOTO2")
> 
>     in ggphoto2volumemonitor.c. This will at least allow people
>     to use custom udev rules to turn of gvfs-gphoto2 handling for
>     a device

Making this change in a local checkout + using my custom rule to change the properties of ID_GPHOTO2 seems to work.  

>  2. If the device is a USB device with a single Mass Storage
>     interface (e.g. class 8) and it has ID_GPHOTO=2 then ignore
>     it as well. That allows us to work around buggy libgphoto2
>     udev rules tagging ID_GPHOTO2=1 for devices that we clearly
>     don't want to use libgphoto2 for.
> 

I wasn't sure how to patch this one, so I can't test that idea too easily.

Thanks again for your help, hopefully fixing this ID will help people hitting this stop scratching their head, on why hot-plugging a mass-storage device crashes things :)

I just ran into what seems to be the same issue with some minor variations.

1) Killing gvfs-gphoto2-volume-monitor alone as a workaround didn't work, I also had to kill gvfs-afc-volume-monitor 

2) I have 2 Fedora 13 boxes which both have the problem (different hardware but very similar configurations), a third machine running Fedora 12 mounts the clip without issue.
Fedora 12 has gvfs-gphoto2-1.4.3-7.f12.i386
Fedora 13 has gvfs-gphoto2-1.6.2-1.fc13.x86_64

I'll see what my ubuntu box does next week.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/101.