linux-kernel - Re: [patch] PM: suspend/resume debugging should depend on SOFTWARE

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]

Date:	Sun, 19 Nov 2006 10:21:52 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Chuck Ebbert <76306.1226@...puserve.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>
Subject: Re: [patch] PM: suspend/resume debugging should depend on 
 SOFTWARE_SUSPEND

On Sun, 19 Nov 2006, Rafael J. Wysocki wrote:
>
> In fact that's up to 30 seconds on a modern box, usually less than that.

Right. If the machine boots quickly, it's fast. Of course, if the machine 
boots quickly, you might as well often just shut down and reboot.

> And suspend-to-ram doesn't work on quilte a lot of boxes right now.  Also, you
> can use the software suspend on boxes that don't support the suspend-to-ram
> at all.

One large reason STR often doesn't work is that people don't even test it, 
because people point to the suspend-to-disk instead.  suspend-to-disk is 
the problem, not the solution.

I've been working at making the machines I have able to STR, and almost 
always it's a driver that is buggy. Thank God for the suspend/resume 
debugging - the thing that Chuck tried to disable. That's often the _only_ 
way to debug these things, and it's actually pretty powerful (but 
time-consuming - having to insert TRACE_RESUME() markers into the device 
driver that doesn't resume and recompile and reboot).

Anyway, the way to debug this for people who are interested (have a 
machine that doesn't boot) is:

 - enable PM_DEBUG, and PM_TRACE

 - use a script like this:

	#!/bin/sh
	sync
	echo 1 > /sys/power/pm_trace
	echo mem > /sys/power/state

   to suspend

 - if it doesn't come back up (which is usually the problem), reboot by 
   holding the power button down, and look at the dmesg output for things 
   like

	Magic number: 4:156:725
	hash matches drivers/base/power/resume.c:28
	hash matches device 0000:01:00.0

   which means that the last trace event was just before trying to resume 
   device 0000:01:00.0. Then figure out what driver is controlling that 
   device (lspci and /sys/devices/pci* is your friend), and see if you can 
   fix it, disable it, or trace into its resume function.

For example, the above happens to be the VGA device on my EVO, which I 
used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out 
that "radeonfb" simply cannot resume that device - it tries to set the 
PLL's, and it just _hangs_. Using the regular VGA console and letting X 
resume it instead works fine.

The point being that PM_TRACE is wonderful, and it's wonderful exactly for 
NOT using suspend-to-disk. The other point being that people have gotten 
lazy, and accept half a minute (minimum - usually it's longer) boot times, 
when STR is a lot more pleasant, but it does require some detective work 
when it doesn't boot.

I wish more people tried STR, instead of having the STD people tell them 
not to!

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