2011/4/8 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Fri, 8 Apr 2011, Zdenek Kabelac wrote: > >> So now I've retested again with my own kernel build - where I've >> disable USB_DEBUG. >> It's somewhat harder to hit the problem - but 2 times I've ended with >> laptop - which >> sent this into '/var/log/messages' >> >> [ 53.851937] btusb_intr_complete: hci0 urb ffff88011735c300 failed >> to resubmit (19) >> [ 53.855223] btusb_bulk_complete: hci0 urb ffff88011735c540 failed >> to resubmit (19) >> [ 53.867211] btusb_bulk_complete: hci0 urb ffff88011735c9c0 failed >> to resubmit (19) >> [ 53.875279] btusb_send_frame: hci0 urb ffff880117204d80 submission failed >> [ 54.127633] systemd[1]: Service bluetooth.target is not needed >> anymore. Stopping. > > Evidently the software undock messed up the Bluetooth device somehow. > >> These are the last lines catched by serial console: >> >> [ 53.340232] usb 1-1: new full speed USB device number 4 using uhci_hcd >> [ 53.505588] usb 1-1: New USB device found, idVendor=0a5c, idProduct=2110 >> [ 53.513035] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 >> [ 53.520876] usb 1-1: Product: BCM2045B >> [ 53.524775] usb 1-1: Manufacturer: Broadcom Corp >> [ 53.846908] usb 1-1: USB disconnect, device number 4 > > It's odd that the Bluetooth device should disconnect shortly after > being detected. However there have been other reports recently about > similar problems with Bluetooth. > Most probably because I've run in the loop while : ; do pm-suspend ; sleep 5; done for debug purposes... >> [ 53.851937] btusb_intr_complete: hci0 urb ffff88011735c300 failed >> to resubmit (19) >> [ 53.855223] btusb_bulk_complete: hci0 urb ffff88011735c540 failed >> to resubmit (19) >> [ 53.867211] btusb_bulk_complete: hci0 urb ffff88011735c9c0 failed >> to resubmit (19) >> [ 53.875279] btusb_send_frame: hci0 urb ffff880117204d80 submission failed >> [ 54.127633] systemd[1]: Service bluetooth.target is not needed >> anymore. Stopping. >> [ 54.205292] PM: Syncing filesystems ... done. >> [ 54.216056] PM: Preparing system for mem sleep >> >> And system was 'dead' - (Moon sign on laptop was already blinking at >> this moment) > > Why did the system suspend like this? A software undock shouldn't > cause a suspend. pm-suspend - with script executed on suspend which undocks laptop (otherwise when I'd forget to press button on docking station before suspend - it would stay 'red' mode - thus all buses are connected - and as I've noticed in past - it's not working well, when I unplug laptop in this 'still connected' mode - so this software 'undock' solved this problem) > >> I've strong believe - it's the moment where USB_DEBUG version was >> printing those lines in endless loop. >> (Or let say it this way: More then few minutes loop - as maybe it >> will end within a week - but I don't have that much time to wait ;)) > > Those debugging messages will continue for as long as the hardware > fails to respond properly. Which is probably 'forever' when the machine is suspending. (note - even SysRq+B no longer works at this moment) Zdenek -- 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
