On Tue, 8 May 2007 15:14:36 -0400, Len Brown wrote:
> On Friday 04 May 2007 03:42, Mikael Pettersson wrote:
> > On Thu, 03 May 2007 19:38:50 -0700, john stultz wrote:
> > > > So that slow acpi_pm on x86_64 seems to be connected w/ the idle loop.
> > > > I'm guessing the chipset halts the ACPI PM in lower C states. Do you
> > > > have any guesses as to what might differ between x86_64 and i386 ACPI
> > > > idle loops? Or might this be something different in what the BIOS
> > > > exports in x86_64 mode or i386 mode?
> > >
> > > Mikael,
> > > Just trying to dig a bit more through the acpi_processor_idle code.
> > > Could you run "cat /proc/acpi/processor/CPU1/power" and reply w/ the
> > > output?
> >
> > Here's that file with the x86-64 kernel:
> >
> > active state: C2
> > max_cstate: C8
> > bus master activity: 00000000
> > maximum allowed latency: 20000 usec
> > states:
> > C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00107840] duration[00000000000000000000]
> > *C2: type[C2] promotion[--] demotion[C1] latency[010] usage[-1987043693] duration[00000000003044809185]
>
> it may be that the problem is C2, not C1 on this box and thus "idle=poll" may be
> overkill to workaround it.
>
> You can disable C2 with "processor.max_cstate=1"
>
> still a mystery, though, why this is different on i386 vs x86_64.
> what is in this file when booted in i386 mode?
With the i386 kernel it's as follows:
active state: C2
max_cstate: C8
bus master activity: 00000000
maximum allowed latency: 20000 usec
states:
C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00004550] duration[00000000000000000000]
*C2: type[C2] promotion[--] demotion[C1] latency[010] usage[00813483] duration[00000000023188005661]
/Mikael
On Wed, 2007-05-09 at 11:11 +0200, Mikael Pettersson wrote:
> On Tue, 8 May 2007 15:14:36 -0400, Len Brown wrote:
> > On Friday 04 May 2007 03:42, Mikael Pettersson wrote:
> > > On Thu, 03 May 2007 19:38:50 -0700, john stultz wrote:
> > > > > So that slow acpi_pm on x86_64 seems to be connected w/ the idle loop.
> > > > > I'm guessing the chipset halts the ACPI PM in lower C states. Do you
> > > > > have any guesses as to what might differ between x86_64 and i386 ACPI
> > > > > idle loops? Or might this be something different in what the BIOS
> > > > > exports in x86_64 mode or i386 mode?
> > > >
> > > > Mikael,
> > > > Just trying to dig a bit more through the acpi_processor_idle code.
> > > > Could you run "cat /proc/acpi/processor/CPU1/power" and reply w/ the
> > > > output?
> > >
> > > Here's that file with the x86-64 kernel:
> > >
> > > active state: C2
> > > max_cstate: C8
> > > bus master activity: 00000000
> > > maximum allowed latency: 20000 usec
> > > states:
> > > C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00107840] duration[00000000000000000000]
> > > *C2: type[C2] promotion[--] demotion[C1] latency[010] usage[-1987043693] duration[00000000003044809185]
> >
> > it may be that the problem is C2, not C1 on this box and thus "idle=poll" may be
> > overkill to workaround it.
> >
> > You can disable C2 with "processor.max_cstate=1"
Hey Mikael,
Did booting w/ processor.max_cstate=1 have the same effect as booting
w/ idle=poll ?
thanks
-john