---- Reported by shotwell-maint@gnome.bugs 2010-09-13 13:31:00 -0700 ----

Original Redmine bug id: 2552
Original URL: http://redmine.yorba.org/issues/2552
Searchable id: yorba-bug-2552
Original author: Jeroen Benckhuijsen
Original description:

Shotwell (0.7.2-1~lucid1, from PPA) experiences constant hangs/not-hang
behaviour. The cause seems to be some interaction with USB devices. dmesg
output:

[ 200.060128] usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd shotwell rqt 128 rq
6 len 255 ret -110

[ 201.060136] usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd shotwell rqt 128 rq
6 len 255 ret -110

[ 202.060134] usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd shotwell rqt 128 rq
6 len 255 ret -110

[ 203.060133] usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd shotwell rqt 128 rq
6 len 255 ret -110

[ 204.060131] usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd shotwell rqt 128 rq
6 len 1000 ret -110

[ 206.230132] usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd shotwell rqt 128 rq
6 len 255 ret -110

[ 207.230134] usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd shotwell rqt 128 rq
6 len 255 ret -110

(etc).

In-between there is some user-interaction possible, but not really usable.



---- Additional Comments From shotwell-maint@gnome.bugs 2010-09-17 14:54:00 -0700 ----

### History

####

#1

Updated by Adam Dingle about 3 years ago

Jason,

is this new behavior for you in 0.7.2? If so, what version of Shotwell were
you using previously – 0.7.1, or another version? What USB devices do you
have attached to your computer? Does the hang/not-hang-behavior happen
constantly whenever Shotwell is running, or only sometimes?

####

#2

Updated by Jim Nelson about 3 years ago

This might be related to [](http://trac.yorba.org/search?q=ticket%3A2269)#2269
(see its upstream ticket for more details:
https://bugs.launchpad.net/ubuntu/source/shotwell/bug/555408)

####

#3

Updated by Jeroen Benckhuijsen about 3 years ago

This is the first version of Shotwell, I'm using, so no reference to earlier
versions.

Attached USB devices:

- HP Photosmart printer/scanner

- Logitech mouse + trackball

- Wacom tablet

- Logitech Webcam

- USB Hub

- Bluetooth dongle

- Mass storage devices (not attached during experience behaviour)

####

#4

Updated by Jeroen Benckhuijsen about 3 years ago

(Oh, and the name is Jeroen ;-))

####

#5

Updated by Jim Nelson about 3 years ago

If you could do the following, it would be helpful:

1. Run this command:

`$ sudo lsusb -v > usb.txt`

And attach the usb.txt file to this ticket.

2. Run Shotwell like this:

`$ SHOTWELL_LOG=1 shotwell`

Reproduce the problem (which I assume happens immediately and constantly) then
exit Shotwell. Attach this file to this ticket: ~/.cache/shotwell/shotwell.log

3. Can you try removing each USB device one-by-one and see which is causing
the problem? I suspect it's one device, not a combination, but who knows.

Thanks!

####

#6

Updated by Jeroen Benckhuijsen about 3 years ago

Just checked by removing the devices. The offending device was the bluetooth
receiver (Bus 002 Device 002: ID 1131:1001 Integrated System Solution Corp.
KY-BT100 Bluetooth Adapter).

####

#7

Updated by Jim Nelson about 3 years ago

Thanks, Jeroen. Looking at this, I believe this to be a different
manifestation of #2269. In both cases, there's a device on the USB bus causing
some sort of problem: timing out, returning an unanticipated error, something
like that. This in turn causes the USB controller (probably in software) to
issue a device reset, or in the least, an internal reset of state.

There's a lot of hand-waving here, but the upshot is it's being reported to
Shotwell as a device detach/attach, and Shotwell then polls the USB bus for
new cameras (or to detect cameras which have gone away). I can see this in
your shotwell.log. Every ten seconds a set of device-removed events and
device-added events are being fired. This is very similar to #2269, although
in that case it was a Kensington mouse causing the trouble.

I have no idea if you need new drivers for your bluetooth receiver, but that
would be worth looking into. On our end, we could do the camera poll in a
background thread, so it's not blocking the UI (which is another indicator
that the device is hanging), and to limit the polling to once every, say,
thirty seconds.

This is non-trivial because gphoto2 is not thread-safe. This might be one more
reason to go to a pure-%(=caps)GVFS% system, as #2498 suggests. For now, all I
can recommend is detaching the bluetooth receiver when using Shotwell.

####

#8

Updated by Jeroen Benckhuijsen about 3 years ago

Indeed, removing the bluetooth device solves the problem. I'll continue to
investigate Shotwell (migrating from F-Spot in preparation Ubuntu/Meerkat).
Current issue is just that tags are not imported hierarchically as present in
F-Spot. I'll file a separate bug for this.

####

#9

Updated by Jim Nelson about 3 years ago

We're aware of this issue. It's ticketed at #1401. Hopefully we'll get to this
soon!



--- Bug imported by chaz@yorba.org 2013-11-25 21:47 UTC  ---

This bug was previously known as _bug_ 2552 at http://redmine.yorba.org/show_bug.cgi?id=2552
Imported an attachment (id=261818)
Imported an attachment (id=261819)

Unknown Component 
   Using default product and component set in Parameters 
Unknown version " in product shotwell. 
   Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell. 
   Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
Resolution set on an open status.
   Dropping resolution