linux-kernel - Re: Suspend/Resume/Hibernation

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: <200711162251.56545.rjw@sisk.pl>
Date:	Fri, 16 Nov 2007 22:51:56 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Kristoffer Ericson <kristoffer.ericson@...il.com>
Cc:	linux-main <linux-kernel@...r.kernel.org>
Subject: Re: Suspend/Resume/Hibernation - bisecting or bug-logs?

On Saturday, 17 of November 2007, Kristoffer Ericson wrote:
> Greetings,
> 
> Ive been following your discussion and documentation efforts concerning pm
> in the kernel. This has in the past been a gray area which was hard to find
> information about so kudos.

Thanks!

> I maintain 2 handheld platforms that would benefit greatly from implementing
> proper pm (mainly suspend) but Im having problems bugtracking it. Currently
> the system tries to suspend but fails somewhere and then tries to resume
> (which fails). The end result however is that Im unable to see anything
> (bugmessages...) since the video driver gets deactivated by pm.

That's bad. 

> My question is this: Is bisecting (turning off device support in kernel until
> it works) the best approach when bugtracking pm suspend?  Or is there any
> other logging system that I can use?    

Well, various approaches are possible.

First, you can build as many drivers as possible as modules and boot with
init=/bin/bash .  Then, try to suspend and resume and if that fails, the
problem is somewhere deeper.  If that goes well, one of the drivers is failing
and you'll need to find it (eg. by bisection).

Second, on x86 we have PM_TRACE which uses the RTC to store some debugging
information that can be used later to identify the point of failure.  This
might be portable to your platforms.

Next, you can use my recent patches (available at
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24-rc2/patches/) to
check how deep the problem is located.

Greetings,
Rafael
-
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/