[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <465C608E.3040303@rtr.ca>
Date: Tue, 29 May 2007 13:19:10 -0400
From: Mark Lord <lkml@....ca>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Alan Stern <stern@...land.harvard.edu>
Cc: Linux Kernel <linux-kernel@...r.kernel.org>,
Greg KH <gregkh@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Regression: USB is nfg after suspend/resume(RAM) cycle on Intel
chipset
Mark Lord wrote:
> I just "upgraded" from 2.6.21.3 to 2.6.22-rc3,
> but will be rebooting back into 2.6.21.xx shortly.
>
> Suspend/Resume (RAM) works perfectly on this Dell i9400 dual-core notebook.
> Except with 2.6.22-rc3, all USB devices are non-functional on resume.
> Most of the time.
> Once in five reboots, my mouse worked after the first suspend/resume cycle,
> but not thereafter. 'lsusb' also hangs after resume.
>
> I'm attaching a full syslog with USB_DEBUG=y.
> I cannot use PM_DEBUG=y due to an unresolved race condition
> in the HRTIMER stuff (previously reported/discussed with no attempt at
> resolution).
>
> This notebook uses very mainstream Intel chips for most stuff:
..
> There are a zillion USB patches in 2.6.22-rc*.
> Greg: got any good suggestions on which one to revert first?
Okay, I used the "targeted revert" method instead of "git-bisect",
and nailed it in one try by reverting these two commits by Alan Stern:
7ed92f1a149dddc3cb537ccd7441e98adac12c3e USB: make the autosuspend workqueue thread freezable
ef7f6c7084b333c7524dcd297e0578d43733a2a2 USB: more autosuspend timer stuff
I yanked them both, as they appeared to be releated based on the titles.
Reverting this pair of commits fixes the USB suspend/resume regression.
Alan Stern: your ball now.
-ml
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists