Re: ACPI PM Timer vs. C1 halt issue

From: Len Brown
Date: Wed Mar 10 2004 - 17:14:51 EST

Yes, C1 is the name they gave for what the idle loop does automatically.

this should be monitor/mwait -- if available -- but currently in ACPI
mode C1 is hard-coded to use HALT -- a bug.

So if your processor has monitor/mwait, and C1 is the best idle state it
has, then you'll probably actually run cooler right now in idle if you
do not load the acpi processor driver. (but if you've got C2, it should
do better than C1 anyway)

That said, I don't know what caused the regression you describe.
Perhaps you can clarfiy the minimal changes necessary to switch between
correct and incorrect behaviour?


On Wed, 2004-03-10 at 16:49, john stultz wrote:
> On Tue, 2004-03-09 at 14:45, Prakash K. Cheemplavam wrote:
> > john stultz wrote:
> > > On Tue, 2004-03-09 at 13:35, Prakash K. Cheemplavam wrote:
> > >
> > >>I found out what causes higher idle temps when using mm-sources and
> > >>2.6.4-rc vanilla sources: If I use PM Timer as timesource, it seems the
> > >>C1 halt isn't properly called, at least CPU disconnect doesn't seem to
> > >>work, thus leaving my CPU as hot as without disconnect.
> > [snip]
> > >
> > > Sounds like a bug. I'm not very familiar w/ the ACPI cpu power states,
> > > is there anything you have to do to trigger C1 Halt? Or is it just
> > > called in the idle loop?
> >
> > It should be called within the idle loop.
> Hmm. I'm still stumped. Looking at acpi_processor_idle(), the C1 state
> doesn't touch the ACPI PM timer. The C2 and C3 states do, but they just
> read.
> Dominik: Do you have a clue on this?
> thanks
> -john

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at