Messages in this thread | | | Date | Fri, 8 Apr 2011 12:39:56 -0400 (EDT) | From | Alan Stern <> | Subject | Re: Endless print of uhci_result_common: failed with status 440000 |
| |
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.
> [ 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.
> 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.
Alan Stern
| |