Re: Endless print of uhci_result_common: failed with status 440000

[Zdenek Kabelac]

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-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/