linux-kernel - [REGRESSION,STABLE,BISECTED] Hang on resume from standby in 3.1.[56], 3.2-rc*

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMDbWJG4u62qmBgxhaYZCuL+5897defC1cy5tNMd+M+9BhWS+g@mail.gmail.com>
Date:	Fri, 23 Dec 2011 11:31:26 -0600
From:	Phil Miller <mille121@...inois.edu>
To:	Thomas Gleixner <tglx@...utronix.de>,
	Greg Kroah-Hartman <greg@...ah.com>, stable@...nel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: [REGRESSION,STABLE,BISECTED] Hang on resume from standby in 3.1.[56], 3.2-rc*

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 <tglx@...utronix.de>
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 <tglx@...utronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>

: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.

If there's anything else I can do to help diagnose this issue or get
it fixed, I'm happy to help.

Thanks.

Phil
--
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/