linux-kernel - Re: macbook pro suspend to ram broken in linux-2.6.git HEAD

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

Message-Id: <1173086567.4196.8.camel@localhost>
Date:	Mon, 05 Mar 2007 10:22:47 +0100
From:	Soeren Sonnenburg <kernel@....de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: macbook pro suspend to ram broken in linux-2.6.git HEAD

On Mon, 2007-03-05 at 09:14 +0100, Ingo Molnar wrote:
> * Soeren Sonnenburg <kernel@....de> wrote:
> 
> > a rather long git bisect session between v2.6.20 and HEAD identified 
> > the commit below this as the cause. please note that the machine does 
> > not return from resume and although all PM debug was turned on there 
> > is nothing in the logs. happens with a minimalistic setup (console 
> > only no audio/network etc) without SMP and CONFIG_HPET_TIMER but 
> > PREEMPT on
> 
> good. Could you apply the patch below, enable CONFIG_PM_DEBUG and 
> CONFIG_PM_TRACE and CONFIG_DISABLE_CONSOLE_SUSPEND, boot into the new 
> kernel and do:
> 
> 	echo 1 > /proc/sys/kernel/acpi_simulate_suspend_to_ram
> 	echo mem > /sys/power/state
> 
> and if the system still works after this point, could you send us the 
> resulting dmesg? Or if it crashes, hopefully the crash should be right 
> on the screen - how does it look like?

I did the following: applied your patch (with the fix that I moved the
acpi_simulate_suspend_to_ram = 1 initialization to the sleep/main.c
file, else compilation fails; I guess that if this should go into the
mainline kernel it should be = 0). I then tested whether the kernel
still works before

e9e2cdb412412326c4827fc78ba27f410d837e6e

with  acpi_simulate_suspend_to_ram_drivers = 0 and = 1. worked.

I then did
git cherry-pick e9e2cdb412412326c4827fc78ba27f410d837e6e

and same procedure:

acpi_... = 0 -> freeze on resume
acpi_... = 1 lead to the attached dmesg output. no crash whatsoever.

Please note that even with CONFIG_DISABLE_CONSOLE_SUSPEND enabled (and
acpi_simulate_suspend_to_ram_drivers = 0) the display turns off and
fails to turn back on (though the machine is still alive after resume as
another s2ram cycle/typeing reboot on the cmdline proves; this can be
fixed using certain s2ram option which however vary between kernel
versions, wrong ones cause again a hang on resume. s2ram -f -p  or s2ram
-f -m).

Soeren.
-- 
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.

View attachment "s2ram-session-dmesg.txt" of type "text/plain" (45476 bytes)