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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
