Source: linux-2.6 Version: 3.1.5-1 Tags: upstream,patch Severity: important Forwarded: [email protected]
I sent the following report to LKML, but diagnosis/repair upstream seems to be moving slowly on it. In particular, it might still appear in the 3.2 release. Others have seen it too, in Ubuntu [1] and Fedora [2]. The bottom line: please revert aeed6baa702a285cf03b7dc4182ffc1a7f4e4ed6 in packaged kernels [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569 [2] https://bugzilla.redhat.com/show_bug.cgi?id=767248 ---------- Forwarded message ---------- From: Phil Miller <[email protected]> Date: Sat, Dec 24, 2011 at 00:40 Subject: Re: [REGRESSION,STABLE,BISECTED] Hang on resume from standby in 3.1.[56], 3.2-rc* To: Thomas Gleixner <[email protected]>, Greg Kroah-Hartman <[email protected]>, [email protected], LKML <[email protected]>, Venkatesh Pallipadi <[email protected]> On Fri, Dec 23, 2011 at 11:31, Phil Miller <[email protected]> wrote: > I've got a Dell Precision T1500 (lspci, dmidecode, and dmesg output at > http://charm.cs.uiuc.edu/~phil/linux-suspend-hang/ ) that I generally > suspend when I'm out of the house or asleep, and wake up when I want > to use it. Sadly, a recent change to the kernel has disrupted that > happy state of affairs. When I run the most recent stable or > pre-release versions, the kernel hangs on resume. I can still switch > virtual consoles, and get keyboard output echoed to the screen, but no > userspace code seems to be running (e.g. login doesn't give me a > password prompt after entering a username), nor does the system > respond to ping or SSH connections. > > Bisection between v3.1 and v3.1.6 points to the following commit as the > culprit: > ===== > commit aeed6baa702a285cf03b7dc4182ffc1a7f4e4ed6 > Author: Thomas Gleixner <[email protected]> > Date: Fri Dec 2 16:02:45 2011 +0100 > > clockevents: Set noop handler in clockevents_exchange_device() > > commit de28f25e8244c7353abed8de0c7792f5f883588c upstream. > > If a device is shutdown, then there might be a pending interrupt, > which will be processed after we reenable interrupts, which causes the > original handler to be run. If the old handler is the (broadcast) > periodic handler the shutdown state might hang the kernel completely. > > Signed-off-by: Thomas Gleixner <[email protected]> > Signed-off-by: Greg Kroah-Hartman <[email protected]> > > :040000 040000 1cfa477e4be68746d7ef2818a430d50424b06572 > ccd4ef67437a19acba03df2debac6eb8c5957b30 M kernel > ===== > > I've tested that reverting this commit also restores my ability to > resume from suspend on 3.2-rc6. I just went digging through the history, and it looks like the commit I found to be problematic partially reverts 7c1e76897492d92b6a1c2d6892494d39ded9680c, from 2008. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/camdbwjegxh5cy5ecvxzq-18nyuhx9edjbri2lytiwljdfp3...@mail.gmail.com
