linux-kernel - Bizzare issue resuming from suspend

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

Date:	Mon, 8 Feb 2010 18:49:32 -0500
From:	"Josh Watzman" <jwatzman@...rew.cmu.edu>
To:	linux-kernel@...r.kernel.org
Subject: Bizzare issue resuming from suspend

Hello,

I'm having some weird issues where my MacBook Pro fails to resume from
suspend. The failure mode is: backlight on, cdrom drive does its "reset"
noise thing, but nothing other than that -- no response to keyboard, for
example, when Control-Alt-F1 then Control-Alt-Delete should reboot.

The following kernels consistently FAIL when resuming:
 - 2.6.32.7 built from kernel.org 2.6.32 tarball + 2.6.32.7 patch
 - 2.6.32.6 built from
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.32.y.git
 - 2.6.32.7 built from
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.32.y.git

The following kernel consistently SUCCEEDS when resuming:
 - 2.6.32.6 built from kernel.org 2.6.32 tarball + 2.6.32.6 patch

Note that 2.6.32.6 either fails or succeeds depending upon how I build it!
To make sure, I built the two variations of .6 on the same day, no system
changes in between, with the same .config, and did a diff -- everything
was the same AFAICT, but the git one fails and the tarball one is fine!

Google suggested to turn on the PM debug options and try a couple of
things; I did the following on the tty of a 2.6.32.6 git build with
.config modified only to turn on PM debugging:
 - run through the /sys/power/pm_test options; it resumes successfully
from everything except "none"
 - echo 1 > /sys/power/pm_trace and use the magic number. dmesg on the
next boot reported the number as "0:168:740" corresponding to
"drivers/base/power/main.c:430" -- it did not report a device

I have no idea how to debug this further -- I'm not (yet ;)) much of a
kernel hacker. If someone wants to help me track it down, I'd love to
help.

Specs:
MacBookPro2,2; Debian sid (not quite up-to-date as I keep things
consistent to track this down); Core 2 Duo 2.33Ghz; 2G ram; 1G swapfile

Thanks! Please CC me on replies, I'm not subscribed.
jwatzman

Sent from webmail -- not digitally signed

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