linux-kernel - Re: swsusp and suspend2 like to overheat my laptop

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:	Wed, 9 Aug 2006 15:42:11 +0200
From:	Andreas Mohr <andi@...x01.fht-esslingen.de>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Pavel Machek <pavel@....cz>,
	LKML <linux-kernel@...r.kernel.org>,
	Suspend2-devel@...ts.suspend2.net, linux-pm@...l.org,
	ncunningham@...uxmail.org
Subject: Re: swsusp and suspend2 like to overheat my laptop

On Wed, Aug 09, 2006 at 09:16:30AM -0400, Steven Rostedt wrote:
> 
> On Wed, 9 Aug 2006, Rafael J. Wysocki wrote:
> 
> >
> > If it's a P4, we rather don't, because the ACPI tables should be above the
> > last pfn in the normal zone.  Still, Steven please send your dmesg after a
> > fresh boot.
> >
> 
> Attached is a gzipped version of my dmesg.

This one is fatal:

| ACPI: Found ECDT
| ACPI: Could not use ECDT

And you also have

| ACPI: Processor [CPU0] (supports 4 throttling states)
| ACPI: Processor [CPU1] (supports 4 throttling states)

(IOW, no C2/C3 states listed here)

The buggy ECDT table (see http://www.poupinou.org/acpi/ibm_ecdt.html)
is said to cause ACPI init to fail:
http://t2100cdt.kippona.net/tlinux/archive/linux.toshiba-dme.co.jp/ML/tlinux-users/4300/4396.html
as such it's not too astonishing that you don't have C2/C3 states, *always*
(pre-suspend and post-suspend).

However the machine should still do normal HLT idle loop which should
manage to keep it reasonably cool, right?

Given this ECDT table issue it's very possible that this is the reason for
Linux ACPI layer misbehaviour after resume.

Google "ACPI ECDT" might help, too.

In any case, you could do some kernel logging around pm_idle* in
drivers/acpi/processor_idle.c since I suspect that this is what changes
after resume to cause the idling to fail.

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