linux-kernel - Re: 3.5-rc7 - can no longer wake up from suspend to RAM

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LSU.2.00.1207211905010.1570@eggly.anvils>
Date:	Sat, 21 Jul 2012 19:07:42 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Roland Dreier <roland@...estorage.com>
cc:	Tomasz Chmielewski <tch@...g.org>, linux-kernel@...r.kernel.org
Subject: Re: 3.5-rc7 - can no longer wake up from suspend to RAM

On Sat, 21 Jul 2012, Roland Dreier wrote:
> On Wed, Jul 18, 2012 at 9:46 PM, Tomasz Chmielewski <tch@...g.org> wrote:
> > After upgrading to 3.5-rc7, my laptop no longer wakes up reliable from suspend to RAM. 3.4.x worked fine.
> 
> FWIW, I've been having similar problems with 3.5-rc7.  With 3.5-rc6 my
> laptop resumed fine, but since updating to -rc7, it often seems to just
> sit there after opening the lid -- the moon/sleep LED stays on, and the
> power LED smoothly cycles on and off, as if it's fast asleep.  Even pressing
> the power button doesn't have any effect (until I hold down the power
> button long enough to turn off).
> 
> I guess I'll start a bisection, but it's slow going because it takes multiple
> tries to know for sure if a kernel is bad.
> 
> The only commit between rc6 and rc7 that looks like it might be related
> is dc332fdf9f373a87b1e2f423b5b004b2a3c37e1a ("ACPI / PM: Leave
> Bus Master Arbitration enabled for suspend/resume"), which apparently
> fixes some other laptops.  But perhaps I'll try reverting that and see how
> it goes.

Interrupt your bisection to try this from 3.5 final:

commit 3e997130bd2e8c6f5aaa49d6e3161d4d29b43ab0
Author: Thomas Gleixner <tglx@...utronix.de>
Date:   Mon Jul 16 12:50:42 2012 -0400

    timekeeping: Add missing update call in timekeeping_resume()
    
    The leap second rework unearthed another issue of inconsistent data.
    
    On timekeeping_resume() the timekeeper data is updated, but nothing
    calls timekeeping_update(), so now the update code in the timer
    interrupt sees stale values.
    
    This has been the case before those changes, but then the timer
    interrupt was using stale data as well so this went unnoticed for quite
    some time.
    
    Add the missing update call, so all the data is consistent everywhere.
    
    Reported-by: Andreas Schwab <schwab@...ux-m68k.org>
    Reported-and-tested-by: "Rafael J. Wysocki" <rjw@...k.pl>
    Reported-and-tested-by: Martin Steigerwald <Martin@...htvoll.de>
    Cc: LKML <linux-kernel@...r.kernel.org>
    Cc: Linux PM list <linux-pm@...r.kernel.org>
    Cc: John Stultz <johnstul@...ibm.com>
    Cc: Ingo Molnar <mingo@...nel.org>
    Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
    Cc: Prarit Bhargava <prarit@...hat.com>
    Cc: stable@...r.kernel.org
    Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
    Signed-off-by: John Stultz <johnstul@...ibm.com>
    Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 269b1fe..3447cfa 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -717,6 +717,7 @@ static void timekeeping_resume(void)
 	timekeeper.clock->cycle_last = timekeeper.clock->read(timekeeper.clock);
 	timekeeper.ntp_error = 0;
 	timekeeping_suspended = 0;
+	timekeeping_update(false);
 	write_sequnlock_irqrestore(&timekeeper.lock, flags);
 
 	touch_softlockup_watchdog();
--
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/