Re: Endless print of uhci_result_common: failed with status 440000

[Alan Stern]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/