Hey, On Tue, Apr 06, 2010 at 08:07:52AM +0200, Oliver Neukum wrote: > > > The only problem: "hciconfig hci0 up" fails to get the device to an useable > > > state again, even if I disable autosuspend again... > > > > That's a new problem. Does the device get autoresumed correctly? If > > yes, then where does the failure occur? Using my patch, the device gets autosuspended and autoresumed correctly (it's bit strange that the intf are interated over the same way during suspend and resume, not in opposite directions). > Exactly. CONFIG_USB_DEBUG should help in discovering what goes > wrong. Strangely, today it seems to work, even though userspace gets confused (especially when mixing disabling bluetooth via "blueman-applet", via bluetooth-applet, and hciconfig hci0 down / up) btusb_intr_complete: hci0 urb ffff88008ba81cc0 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff88008ba81c00 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff88008ba81840 failed to resubmit (1) btusb_intr_complete: hci0 urb ffff88008bbfce40 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff88008bbfca80 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff88008bbfcb40 failed to resubmit (1) These appear approximately when the _resume() callbacks are called; prolonging the autosuspend period does not help. Bluetooth still _seems_ to work fine, sometimes I do get reports such as: root@comet:~# hciconfig hci0 up Can't init device hci0: Unknown error 132 (132) and userspace (especially blueman-applet) seems to get confused a bit. Best, Dominik -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
