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
