Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1766871AbXEBT73 (ORCPT ); Wed, 2 May 2007 15:59:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1766873AbXEBT73 (ORCPT ); Wed, 2 May 2007 15:59:29 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:59993 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1766871AbXEBT72 (ORCPT ); Wed, 2 May 2007 15:59:28 -0400 Date: Wed, 2 May 2007 15:59:26 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Mark Lord cc: Linux Kernel , , Greg KH , Andrew Morton , Subject: Re: [linux-usb-devel] [BUG] usb/core/hub.c loops forever on resume from ram due to bluetooth In-Reply-To: <4637CD25.5070104@rtr.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1509 Lines: 42 On Tue, 1 May 2007, Mark Lord wrote: > 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. A better approach would be to find out why your system gets into that loop and fix the underlying cause. Alan Stern - 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/