linux-kernel - Debugging Thinkpad T430s occasional suspend failure.

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: <20130212193901.GA18906@redhat.com>
Date:	Tue, 12 Feb 2013 14:39:01 -0500
From:	Dave Jones <davej@...hat.com>
To:	Linux Kernel <linux-kernel@...r.kernel.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Debugging Thinkpad T430s occasional suspend failure.

My Thinkpad T430s suspend/resumes fine most of the time. But every so often
(like one in ten times or so), as soon as I suspend, I get a black screen,
and a blinking power button.

(Note: Not the capslock lights like when we panic, this laptop 'conveniently
 doesn't have those. This is the light surrounding the power button, which afaik
 isn't even OS controlled, so maybe we're dying somewhere in SMI/BIOS land?)

I tried debugging this with pm_trace, which told me..

[    4.576035]   Magic number: 0:455:740
[    4.576037]   hash matches drivers/base/power/main.c:645

Which points me at..

 642  Complete:
 643         complete_all(&dev->power.completion);
 644 
 645         TRACE_RESUME(error);
 646 
 647         return error;
 648 }

The only thing interesting here I think is that this is the resume path.
So perhaps something failed to suspend, and we tried to back out of suspending,
but something was too screwed up to abort cleanly ?

I've tried hooking up a serial console, and even tried console_noblank, 
which yielded no additional info at all. (I'm guessing the consoles are suspended
at the time of panic)

I also tried unloading all the modules I have loaded before the suspend, which
seemed to reduce the chances of it happening, but eventually it reoccurred.

Any ideas on how I can further debug this ?

	Dave

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