[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libreboot] Suspend-to-RAM survey

From: Denis 'GNUtoo' Carikli
Subject: Re: [Libreboot] Suspend-to-RAM survey
Date: Tue, 1 Dec 2015 16:12:49 +0100

On Fri, 13 Nov 2015 00:11:25 -0500
"Patrick 'P. J.' McDermott" <address@hidden> wrote:

> Dear libreboot users,

> I'm investigating an issue with suspend-to-RAM that occurs on some
> X200, R400, T400, and T500 laptops.
I don't have such hardware but, instead, I've advises on how to get the
data you are looking for.

> Could anyone with such a laptop running libreboot try suspending to
> RAM (i.e. closing the lid with Trisquel, not suspending to disk a.k.a.
> hibernating) and then resuming a few times (as many times as you can)
> and provide me with the following information (off-list directly to me
> is fine):
You could provide a script that uses rtcwake to wakeup from suspend.
Such scripts are common to investigate suspend/resume issues.
A famous example: The OpenMoko Freerunner did suspend most of the time,
the ratio where it didn't was 1/100 or even lower. Since you can't
expect developers to manually suspend more than 100 times to reproduce
the issue, it's automatized trough scripting. Then the developer was
supposed to use kgdb or JTAG to debug the issue.

>   * Whether resuming from suspend-to-RAM works every time;
There might probably be something within Linux or some userspace
programs to do that with less reliability than memtest86+

Else you could use coreboot/libreboot to do the checks:
At resume, coreboot and libreboot re-run, they then detect that the
computer is resuming and do whatever it takes to permit the resume.

Note that coreboot also has GDB support. Use with care as the
CONFIG_GDB_WAIT option will probably wait on the default serial port
for a gdb connection, but you don't have a serial port on such
So don't try if you don't intend to reflash externally afterward.

>   * If not, what happens instead, in as much detail as possible;
The script could ask the user at the end, but still permit the user to
easily modify what he submit later on somehow.
Else it's particularly frustrating, like with the terminal-profile

>   * The contents of /proc/cpuinfo; and
Can be gathered by the script.

>   * The libreboot version being used, if known.
Can also be gathered by the script. In parabola linux-libre permits it.
The same should be valid for Trisquel.

The Parabola -grsec kenrels don't, but they are known to break suspend
to RAM(it's a feature), as it is incompatible with some of the security
features they activated. So ignore -grsec kenrels.


Attachment: pgpLjqhC9GO2A.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]