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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ