http://bugzilla.kernel.org/show_bug.cgi?id=6519
------- Additional Comments From [EMAIL PROTECTED] 2006-05-15 13:08 -------
On Mon, 15 May 2006, Dave Jenkins wrote:
>
> --- Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > Do you actally see anything running hotter?
>
> Yes, that's how this problem manifests itself and the only means by
> which I became aware of it. In the working case, without "if
> (pr->power.states[i].type >= ACPI_STATE_C2)", my CPU idle temperature
> is around 36 degrees C. In the non-working case, with that "if"
> statement, the idle temp is around 51 degrees C. The CPU temp was my
> sole guide during the git bisect.
Good job. That's certainly conclusive.
> > Please realize that we will _always_ use C1 (aka "halt") in the idle state
> > quite regardless of ACPI - unless you've done "idle=poll" on the kernel
> > command line. So the fact that we don't use ACPI for it shouldn't make us
> > actually run any hotter (quite the reverse - we'll go into C1 state with
> > _less_ work).
>
> Interesting. I'm not using "idle=poll". I should re-iterate that I know
> nothing about kernel internals, but I'm wondering, given what you've
> said, if its possible that there's another problem here, causing
> non-ACPI C1/halt not to work.
I'd also wonder if maybe there is something that causes ACPI to go into C2
even though the BIOS latency tables have apparently said that we
shouldn't.
Ie it may be that we have a totally unrelated bug that made ACPI actually
go into a deeper powersaving mode than it should. That could have
explained the lockups that Maneesh saw with "maxcpus=1" (because C2 and
above are disabled for SMP _anyway_, since they aren't valid there due to
touching the _common_ northbridge rather than being per-core).
> Thus ACPI is the only mechanism providing
> power-saving; and was only doing so, prior to the "if
> (pr->power.states[i].type >= ACPI_STATE_C2)" revision, due to a happy
> accident whereby a valid C1 state in pr->power.states caused
> pr->flags.power to be set. Does that make any sense?
Actually, suddenly it does. When I look more closely at your dmesg report,
I find this:
Checking 'hlt' instruction... disabled
ie your normal idle loop has literally _disabled_ the use of hlt.
Do you have "no-hlt" on the kernel command line? That _should_ be the only
thing that disables hlt (and thus power-savings in idle).
Yup, you do (from that same dmesg):
Kernel command line: ro root=/dev/VolGroup00/LogVol00 no-hlt 1
And yes, ACPI will ignore that "no-hlt" flag.
Now, the question is, why do you have no-hlt there? Was it some strange
distro that set it for you? And why?
Linus
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
