Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64

Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64

[john stultz]

On Tue, 2007-04-17 at 10:09 -0700, Andrew Morton wrote:
> I guess this counts as a regression.
> 
> Begin forwarded message:
> 
> Date: Tue, 17 Apr 2007 14:16:25 +0200 (MEST)
> From: Mikael Pettersson 	
> To: linux-kernel@vger.kernel.org
> Subject: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64
> 
> 
> The machine is an old Athlon64 laptop (Targa Visionary 811,
> OEMd as the Arima W720-K8, also sold as the eMachines m6805)
> with a VIA K8T800 chipset. ACPI is enabled.
> 
> Up to kernel 2.6.20, time-keeping worked fine. In the
> x86-64 kernel, the clock source is listed as "jiffies".
> 
> With current 2.6.21-rc7, the x86-64 kernel selects
> acpi_pm as its clock source. Unfortunately, with this
> clock time drifts and it loses several minutes per hour.
> 
> What's strange is that the i386 kernel on the same
> machine (with similar .config) does not lose time
> while using the acpi_pm clock source.

Huh. Quite strange as its the same acpi_pm clocksource driver!

The only difference I see right off is that verify_pmtmr_rate() isn't
done on x86_64. Although I'd expect you'd see "PM-Timer running at
invalid rate" w/ the i386 kernel if it made a difference.

Could you send me the dmesg output for both the x86_64 and i386 kernels
you tried?

thanks
-john

Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64

[john stultz]

On Sun, 2007-04-29 at 17:24 +0200, Mikael Pettersson wrote:
> On Thu, 26 Apr 2007 15:42:44 -0700, john stultz wrote:
> >Another shot in the dark:
> >
> >I wonder if the ACPI PM counter is halting in idle. Does booting w/
> >idle=poll change the behavior? (Please do this while your laptop is
> >plugged in, as it will run the cpu at full speed all the time).
> 
> Bingo!

Awesome! Finally, some progress! Thanks again for putting up w/ all my
testing requests.

> I booted the x86-64 2.6.21 final kernel with idle=poll and let the
> laptop idle for an hour. The ondemand cpufreq governor did reduce
> the CPU's clock frequency, but that shouldn't have affected the
> chipset or the ACPI PM counter.
> 
> Anyway, after 60 minutes `date' and `hwclock' were still in perfect
> sync and matched actual time.
> 
> Any ideas why this halting in idle doesn't happen with the 32-bit kernel?

No clue. Time to ask Len. :)

Hey Len,
	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?

Any suggestions on how to dig through this?


Thomas: Heads up, the ACPI PM might be flakier then we thought.

thanks
-john

Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64

[john stultz]

On Wed, 2007-05-02 at 11:10 -0700, john stultz wrote:
> On Sun, 2007-04-29 at 17:24 +0200, Mikael Pettersson wrote:
> > On Thu, 26 Apr 2007 15:42:44 -0700, john stultz wrote:
> > >Another shot in the dark:
> > >
> > >I wonder if the ACPI PM counter is halting in idle. Does booting w/
> > >idle=poll change the behavior? (Please do this while your laptop is
> > >plugged in, as it will run the cpu at full speed all the time).
> > 
> > Bingo!
> 
> Awesome! Finally, some progress! Thanks again for putting up w/ all my
> testing requests.
> 
> > I booted the x86-64 2.6.21 final kernel with idle=poll and let the
> > laptop idle for an hour. The ondemand cpufreq governor did reduce
> > the CPU's clock frequency, but that shouldn't have affected the
> > chipset or the ACPI PM counter.
> > 
> > Anyway, after 60 minutes `date' and `hwclock' were still in perfect
> > sync and matched actual time.
> > 
> > Any ideas why this halting in idle doesn't happen with the 32-bit kernel?
> 
> No clue. Time to ask Len. :)
> 
> Hey Len,
> 	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?

thanks
-john

Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64

[Mikael Pettersson]

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]

/Mikael

Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64

[Len Brown]

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?

-Len

Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64

[Mikael Pettersson]

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

Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64

[john stultz]

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

Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64

[Mikael Pettersson]

On Thu, 10 May 2007 11:52:33 -0700, john stultz wrote:
> 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 ?

It seems so. `/sbin/hwclock' and `date' are still in sync after 60 minutes,
where previously `date' would lag behind by about 3 minutes.

/Mikael