Re: for USB guys - strange things in dmesg

From: Pete Zaitcev
Date: Sat Jan 08 2005 - 18:04:04 EST


On Thu, 30 Dec 2004 21:13:00 +0100, Michal Semler <cijoml@xxxxxxxx> wrote:

> when inserting my Bluetooth dongle into USB port, I get into dmesg this:
> Bluetooth: RFCOMM ver 1.4
> Bluetooth: RFCOMM socket layer initialized
> Bluetooth: RFCOMM TTY layer initialized
> drivers/usb/input/hid-core.c: input irq status -84 received

>[.... LONG flood of the same messages ....]

> drivers/usb/input/hid-core.c: input irq status -84 received
> usb 3-1: USB disconnect, address 3
> drivers/usb/input/hid-core.c: input irq status -84 received
> drivers/usb/input/hid-core.c: can't resubmit intr, 0000:00:1d.2-1/input1, status -19
> usb 3-1: new full speed USB device using uhci_hcd and address 4
> Bluetooth: HCI USB driver ver 2.7

What happens here is that the device disconnects itself during or after
it's initialized.

Once the HC hardware detects the disconnect, future URBs will end with
-84 error. However, the HID driver does not do anything about it.
It continues to attempt to resubmit until the khubd does its processing
and enters its disconnect method. In extreme cases, it is possible to
have this submit-and-error-and-repeat loop to monopolize the CPU and
prevent khubd from working ever, thus effectively locking up the box.
Fortunately, in 2.6 kernel we standardized error codes, and thus drivers
like hid can rely on -84 meaning a disconnect and not something else.
In such case, hid has to stop resubmitting before its disconnect method
is executed.

This is relevant to all drivers which submit interrupt URBs. One driver
which does it correctly is mct_u232 (surprisingly enough), so the code
can be taken from there.

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