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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/