LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64
@ 2007-05-04  7:42 Mikael Pettersson
  2007-05-08 19:14 ` Len Brown
  0 siblings, 1 reply; 8+ messages in thread
From: Mikael Pettersson @ 2007-05-04  7:42 UTC (permalink / raw)
  To: johnstul, mikpe; +Cc: ak, len.brown, linux-kernel, tglx

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64
  2007-05-04  7:42 Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64 Mikael Pettersson
@ 2007-05-08 19:14 ` Len Brown
  0 siblings, 0 replies; 8+ messages in thread
From: Len Brown @ 2007-05-08 19:14 UTC (permalink / raw)
  To: Mikael Pettersson; +Cc: johnstul, ak, linux-kernel, tglx

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64
@ 2007-05-13 21:30 Mikael Pettersson
  0 siblings, 0 replies; 8+ messages in thread
From: Mikael Pettersson @ 2007-05-13 21:30 UTC (permalink / raw)
  To: johnstul, mikpe; +Cc: ak, lenb, linux-kernel, tglx

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64
  2007-05-09  9:11 Mikael Pettersson
@ 2007-05-10 18:52 ` john stultz
  0 siblings, 0 replies; 8+ messages in thread
From: john stultz @ 2007-05-10 18:52 UTC (permalink / raw)
  To: Mikael Pettersson; +Cc: lenb, ak, linux-kernel, tglx

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64
@ 2007-05-09  9:11 Mikael Pettersson
  2007-05-10 18:52 ` john stultz
  0 siblings, 1 reply; 8+ messages in thread
From: Mikael Pettersson @ 2007-05-09  9:11 UTC (permalink / raw)
  To: lenb, mikpe; +Cc: ak, johnstul, linux-kernel, tglx

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64
  2007-05-02 18:10 ` john stultz
@ 2007-05-04  2:38   ` john stultz
  0 siblings, 0 replies; 8+ messages in thread
From: john stultz @ 2007-05-04  2:38 UTC (permalink / raw)
  To: Mikael Pettersson; +Cc: Len Brown, Thomas Gleixner, lkml, Andi Kleen

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64
       [not found] <200704291524.l3TFOL9j013216@harpo.it.uu.se>
@ 2007-05-02 18:10 ` john stultz
  2007-05-04  2:38   ` john stultz
  0 siblings, 1 reply; 8+ messages in thread
From: john stultz @ 2007-05-02 18:10 UTC (permalink / raw)
  To: Mikael Pettersson; +Cc: Len Brown, Thomas Gleixner, lkml, Andi Kleen

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




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64
       [not found] <20070417100942.c990604b.akpm@linux-foundation.org>
@ 2007-04-17 20:12 ` john stultz
  0 siblings, 0 replies; 8+ messages in thread
From: john stultz @ 2007-04-17 20:12 UTC (permalink / raw)
  To: mikpe; +Cc: Ingo Molnar, Thomas Gleixner, Adrian Bunk, lkml, Andrew Morton

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2007-05-13 21:33 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-05-04  7:42 Fw: [BUG 2.6.21-rc7] acpi_pm clocksource loses time on x86-64 Mikael Pettersson
2007-05-08 19:14 ` Len Brown
  -- strict thread matches above, loose matches on Subject: below --
2007-05-13 21:30 Mikael Pettersson
2007-05-09  9:11 Mikael Pettersson
2007-05-10 18:52 ` john stultz
     [not found] <200704291524.l3TFOL9j013216@harpo.it.uu.se>
2007-05-02 18:10 ` john stultz
2007-05-04  2:38   ` john stultz
     [not found] <20070417100942.c990604b.akpm@linux-foundation.org>
2007-04-17 20:12 ` john stultz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).