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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
