From: Mark Lord <lkml@rtr.ca>
To: Linux Kernel <linux-kernel@vger.kernel.org>,
Greg KH <gregkh@suse.de>, Andrew Morton <akpm@osdl.org>
Cc: marcel@holtmann.org
Subject: Re: [BUG] usb/core/hub.c loops forever on resume from ram due to bluetooth
Date: Tue, 08 May 2007 09:53:05 -0400 [thread overview]
Message-ID: <464080C1.6010105@rtr.ca> (raw)
In-Reply-To: <4637CD25.5070104@rtr.ca>
Greg ?
The oddball thing here is that on a UP machine with a UP kernel,
this (below) was never an issue.
After moving the drive to a dual-core machine and rebuilding
the kernel with SMP=y, the problem becomes a killer here.
The two machines are nearly identical, apart from the CPUs.
The failing machine is a Dell Inspiron 9400,
and mine isn't the only unit that has this issue.
----------Original message:
I have just replaced my primary single-core notebook
with a nearly identical dual-core notebook,
and moved the usb-bluetooth peripheral from the old
machine to the new one.
On the single-core machine, suspend/resume (RAM) worked
fine even with the bluetooth module enabled.
On the new dual-core machine, resuming with bluetooth
enabled results in an infinite(?) lockup in an unbounded
loop in hub_tt_kevent(). With PM debug on, I see
tens of thousands of these messages scrolling on the console:
kernel: usb 5-1: clear tt 4 (9042) error -71
kernel: usb 5-1: clear tt 4 (9042) error -71
kernel: usb 5-1: clear tt 4 (9042) error -71
(over and over and ...)
By restricting iterations on the unbounded loop
the machine is able to resume again.
Greg / Marcel: any words of wisdom?
And we should probably put bounds permanently on that loop:
I devised/used this patch to accomplish it.
Now, I still get close to a thousand or so such
messages, in groups, showing up in syslog,
but at least the system can resume after suspend.
Signed-off-by: Mark Lord <mlord@pobox.com>
--- linux/drivers/usb/core/hub.c.orig 2007-04-26 12:02:47.000000000 -0400
+++ linux/drivers/usb/core/hub.c 2007-05-01 18:48:46.000000000 -0400
@@ -403,9 +403,10 @@
struct usb_hub *hub =
container_of(work, struct usb_hub, tt.kevent);
unsigned long flags;
+ int limit = 500;
spin_lock_irqsave (&hub->tt.lock, flags);
- while (!list_empty (&hub->tt.clear_list)) {
+ while (--limit && !list_empty (&hub->tt.clear_list)) {
struct list_head *temp;
struct usb_tt_clear *clear;
struct usb_device *hdev = hub->hdev;
-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2007-05-08 13:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-01 23:28 [BUG] usb/core/hub.c loops forever on resume from ram due to bluetooth Mark Lord
2007-05-02 19:59 ` [linux-usb-devel] " Alan Stern
2007-05-02 21:39 ` Mark Lord
2007-05-03 13:33 ` Alan Stern
2007-05-03 13:44 ` Mark Lord
2007-05-03 14:46 ` Alan Stern
2007-05-08 13:53 ` Mark Lord [this message]
2007-05-13 9:27 ` Greg KH
2007-05-14 23:48 ` Mark Lord
2007-05-22 23:53 ` patch usb-hub.c-loops-forever-on-resume-from-ram-due-to-bluetooth.patch added to gregkh-2.6 tree gregkh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=464080C1.6010105@rtr.ca \
--to=lkml@rtr.ca \
--cc=akpm@osdl.org \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.