linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: for USB guys - strange things in dmesg
       [not found] <mailman.1104438600.3923.linux-kernel2news@redhat.com>
@ 2005-01-08 23:00 ` Pete Zaitcev
  2005-01-11 14:21   ` Vojtech Pavlik
  2005-01-11 16:37   ` Vojtech Pavlik
  0 siblings, 2 replies; 5+ messages in thread
From: Pete Zaitcev @ 2005-01-08 23:00 UTC (permalink / raw)
  To: cijoml, linux-kernel, vojtech; +Cc: linux-usb-deve

On Thu, 30 Dec 2004 21:13:00 +0100, Michal Semler <cijoml@volny.cz> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: for USB guys - strange things in dmesg
  2005-01-08 23:00 ` for USB guys - strange things in dmesg Pete Zaitcev
@ 2005-01-11 14:21   ` Vojtech Pavlik
  2005-01-11 16:37   ` Vojtech Pavlik
  1 sibling, 0 replies; 5+ messages in thread
From: Vojtech Pavlik @ 2005-01-11 14:21 UTC (permalink / raw)
  To: Pete Zaitcev; +Cc: cijoml, linux-kernel, linux-usb-deve

On Sat, Jan 08, 2005 at 03:00:03PM -0800, Pete Zaitcev wrote:
> On Thu, 30 Dec 2004 21:13:00 +0100, Michal Semler <cijoml@volny.cz> 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.

-84 is, according to documentation, -EILSEQ, and means "a CRC error",
that shouldn't normally happen and "indicates hardware problems such as
bad devices (including firmware) or cables".

I'm getting -84 on disconnect now, too, which suggests that uhci-hcd
might be using incorrect error code here.

Looking at uhci-hcd, it reports -EILSEQ in case there is a timeout on
the bus talking to the device. This can happen due to a disconnect, but
the HC should notice the disconnect I believe and return the right error
code.

Disconnects (-ESHUTDOWN) are already handled by hid-core.c

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

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: for USB guys - strange things in dmesg
  2005-01-08 23:00 ` for USB guys - strange things in dmesg Pete Zaitcev
  2005-01-11 14:21   ` Vojtech Pavlik
@ 2005-01-11 16:37   ` Vojtech Pavlik
  1 sibling, 0 replies; 5+ messages in thread
From: Vojtech Pavlik @ 2005-01-11 16:37 UTC (permalink / raw)
  To: Pete Zaitcev; +Cc: cijoml, linux-kernel, linux-usb-deve

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

On Sat, Jan 08, 2005 at 03:00:03PM -0800, Pete Zaitcev wrote:
> On Thu, 30 Dec 2004 21:13:00 +0100, Michal Semler <cijoml@volny.cz> 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.
 
Can you test this patch? It seems to work for me.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

[-- Attachment #2: hid-disconnect-fix --]
[-- Type: text/plain, Size: 2466 bytes --]

ChangeSet@1.1970, 2005-01-11 17:33:17+01:00, vojtech@silver.ucw.cz
  input: Handle -EILSEQ return code in the HID driver completion
         handlers as unplug.
         Flush request queue on unplug, too.
         
  Signed-off-by: Vojtech Pavlik <vojtech@suse.cz>


 hid-core.c |   23 ++++++++++++++++++-----
 1 files changed, 18 insertions(+), 5 deletions(-)


diff -Nru a/drivers/usb/input/hid-core.c b/drivers/usb/input/hid-core.c
--- a/drivers/usb/input/hid-core.c	2005-01-11 17:34:52 +01:00
+++ b/drivers/usb/input/hid-core.c	2005-01-11 17:34:52 +01:00
@@ -925,8 +925,9 @@
 			break;
 		case -ECONNRESET:	/* unlink */
 		case -ENOENT:
-		case -ESHUTDOWN:
 		case -EPERM:
+		case -ESHUTDOWN:	/* unplug */
+		case -EILSEQ:		/* unplug timeout on uhci */
 			return;
 		case -ETIMEDOUT:	/* NAK */
 			break;
@@ -1136,12 +1137,15 @@
 {
 	struct hid_device *hid = urb->context;
 	unsigned long flags;
+	int unplug = 0;
 
 	switch (urb->status) {
 		case 0:			/* success */
+		case -ESHUTDOWN:	/* unplug */
+		case -EILSEQ:		/* unplug timeout on uhci */
+			unplug = 1;
 		case -ECONNRESET:	/* unlink */
 		case -ENOENT:
-		case -ESHUTDOWN:
 			break;
 		default:		/* error */
 			warn("output irq status %d received", urb->status);
@@ -1149,7 +1153,10 @@
 
 	spin_lock_irqsave(&hid->outlock, flags);
 
-	hid->outtail = (hid->outtail + 1) & (HID_OUTPUT_FIFO_SIZE - 1);
+	if (unplug)
+		hid->outtail = hid->outhead;
+	else
+		hid->outtail = (hid->outtail + 1) & (HID_OUTPUT_FIFO_SIZE - 1);
 
 	if (hid->outhead != hid->outtail) {
 		if (hid_submit_out(hid)) {
@@ -1173,6 +1180,7 @@
 {
 	struct hid_device *hid = urb->context;
 	unsigned long flags;
+	int unplug = 0;
 
 	spin_lock_irqsave(&hid->ctrllock, flags);
 
@@ -1180,16 +1188,21 @@
 		case 0:			/* success */
 			if (hid->ctrl[hid->ctrltail].dir == USB_DIR_IN) 
 				hid_input_report(hid->ctrl[hid->ctrltail].report->type, urb, regs);
+		case -ESHUTDOWN:	/* unplug */
+		case -EILSEQ:		/* unplug timectrl on uhci */
+			unplug = 1;
 		case -ECONNRESET:	/* unlink */
 		case -ENOENT:
-		case -ESHUTDOWN:
 		case -EPIPE:		/* report not available */
 			break;
 		default:		/* error */
 			warn("ctrl urb status %d received", urb->status);
 	}
 
-	hid->ctrltail = (hid->ctrltail + 1) & (HID_CONTROL_FIFO_SIZE - 1);
+	if (unplug)
+		hid->ctrltail = hid->ctrlhead;
+	else
+		hid->ctrltail = (hid->ctrltail + 1) & (HID_CONTROL_FIFO_SIZE - 1);
 
 	if (hid->ctrlhead != hid->ctrltail) {
 		if (hid_submit_ctrl(hid)) {

^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: for USB guys - strange things in dmesg
@ 2005-01-09 16:48 David Brownell
  0 siblings, 0 replies; 5+ messages in thread
From: David Brownell @ 2005-01-09 16:48 UTC (permalink / raw)
  To: Linux Kernel list

[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]

Pete Zaitcev writes:
> 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.

Right ... -EILSEQ one of those awkward faults that can appear both during
disconnect processing and during normal operation.  So it's never clear
when a driver should treat it as fatal or try to recover.


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

Right ... these being two separate problems:  (a) too much resubmitting,
and (b) too much printk.  The resubmitting is barely noticeable in terms
of load (and HID doesn't track such faults), but the printks are trouble.

For (b), printk_ratelimit() would be an appropriate fix for HID and
other drivers that log this fault and then attempt to recover by
resubmitting.  The attached patch should help.


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

That's not  true; -EILSEQ doesn't always indicate disconnect.
See Documentation/usb/error-oodes.txt ...


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

Since mct_u232 treats -EILSEQ as always-fatal, when it's not, that's not
the best example.  I think a better example is usbnet, which handles this
fault -- for bulk RX and TX of network packets, it doesn't currently use
interrupt URBs! -- by briefly throttling back traffic.  (It also has more
complete handling of other urb->status values than most other drivers.)

During disconnect processing, there's neither log flooding nor hundreds of
false network errors; during normal processing, there's still a chance for
hardware to recover itself.

- Dave

[-- Attachment #2: hid.patch --]
[-- Type: text/x-diff, Size: 558 bytes --]

Ratelimit some HID messages that can happen during disconnect processing.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

--- 1.105/drivers/usb/input/hid-core.c	2005-01-07 20:55:37 -08:00
+++ edited/drivers/usb/input/hid-core.c	2005-01-09 08:40:17 -08:00
@@ -931,7 +931,9 @@
 		case -ETIMEDOUT:	/* NAK */
 			break;
 		default:		/* error */
-			warn("input irq status %d received", urb->status);
+			if (!printk_ratelimit())
+				warn("input irq status %d received",
+						urb->status);
 	}
 	
 	status = usb_submit_urb(urb, SLAB_ATOMIC);

^ permalink raw reply	[flat|nested] 5+ messages in thread
* for USB guys - strange things in dmesg
@ 2004-12-30 20:13 Michal Semler
  0 siblings, 0 replies; 5+ messages in thread
From: Michal Semler @ 2004-12-30 20:13 UTC (permalink / raw)
  To: linux-kernel

Hi guys,

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
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
drivers/usb/input/hid-core.c: input irq status -84 received
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
usbcore: registered new driver hci_usb
------
Dongle boots in HID proxy mode, then is switched - list is the same after 
switching.
But USB dongle normally works.

Thanks for fixing

Michal 

^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-01-11 17:03 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <mailman.1104438600.3923.linux-kernel2news@redhat.com>
2005-01-08 23:00 ` for USB guys - strange things in dmesg Pete Zaitcev
2005-01-11 14:21   ` Vojtech Pavlik
2005-01-11 16:37   ` Vojtech Pavlik
2005-01-09 16:48 David Brownell
  -- strict thread matches above, loose matches on Subject: below --
2004-12-30 20:13 Michal Semler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).