public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Linux 2.6.21: pmtmr losing time
@ 2007-04-30 12:52 Joerg Sommrey
  2007-04-30 16:23 ` Thomas Gleixner
  0 siblings, 1 reply; 6+ messages in thread
From: Joerg Sommrey @ 2007-04-30 12:52 UTC (permalink / raw)
  To: Linux kernel mailing list

Hi all,

after switching to 2.6.21 the system clock sporadically loses time on my
box (i386, Athlon MP).
It's always around 4.68 seconds and happened 7 times in the last 12
hours.  A simple calculation (2 ^ ACPI_PM_MASK / PMTMR_TICKS_PER_SEC =
2 ^ 24 / 3579545 = 4.686968875) shows: There is almost exactly one
pmtmr-cycle missing.  Could this be caused by a pmtmr-wrap when the
system is in a sleep state? 

-jo

-- 
-rw-r--r-- 1 jo users 62 2007-04-29 22:29 /home/jo/.signature

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

* Re: Linux 2.6.21: pmtmr losing time
  2007-04-30 12:52 Linux 2.6.21: pmtmr losing time Joerg Sommrey
@ 2007-04-30 16:23 ` Thomas Gleixner
  2007-04-30 16:39   ` Joerg Sommrey
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas Gleixner @ 2007-04-30 16:23 UTC (permalink / raw)
  To: Joerg Sommrey; +Cc: Linux kernel mailing list

On Mon, 2007-04-30 at 14:52 +0200, Joerg Sommrey wrote:
> Hi all,
> 
> after switching to 2.6.21 the system clock sporadically loses time on my
> box (i386, Athlon MP).
> It's always around 4.68 seconds and happened 7 times in the last 12
> hours.  A simple calculation (2 ^ ACPI_PM_MASK / PMTMR_TICKS_PER_SEC =
> 2 ^ 24 / 3579545 = 4.686968875) shows: There is almost exactly one
> pmtmr-cycle missing.  Could this be caused by a pmtmr-wrap when the
> system is in a sleep state? 

Hmm, looks like. That's strange we don't sleep 4.68 seconds. Can you
provide me the output of /proc/timer_list please ?

	tglx



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

* Re: Linux 2.6.21: pmtmr losing time
  2007-04-30 16:23 ` Thomas Gleixner
@ 2007-04-30 16:39   ` Joerg Sommrey
  2007-04-30 21:38     ` Thomas Gleixner
  0 siblings, 1 reply; 6+ messages in thread
From: Joerg Sommrey @ 2007-04-30 16:39 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Linux kernel mailing list

On Mon, Apr 30, 2007 at 06:23:36PM +0200, Thomas Gleixner wrote:
> On Mon, 2007-04-30 at 14:52 +0200, Joerg Sommrey wrote:
> > Hi all,
> > 
> > after switching to 2.6.21 the system clock sporadically loses time on my
> > box (i386, Athlon MP).
> > It's always around 4.68 seconds and happened 7 times in the last 12
> > hours.  A simple calculation (2 ^ ACPI_PM_MASK / PMTMR_TICKS_PER_SEC =
> > 2 ^ 24 / 3579545 = 4.686968875) shows: There is almost exactly one
> > pmtmr-cycle missing.  Could this be caused by a pmtmr-wrap when the
> > system is in a sleep state? 
> 
> Hmm, looks like. That's strange we don't sleep 4.68 seconds. Can you
> provide me the output of /proc/timer_list please ?
> 
> 	tglx
> 
> 

Here it is.  Maybe this problem is related to the usage of the
"experimental" amd76x_pm module?

-jo

Timer List Version: v0.3
HRTIMER_MAX_CLOCK_BASES: 2
now at 249154808025750 nsecs

cpu: 0
 clock 0:
  .index:      0
  .resolution: 1 nsecs
  .get_time:   ktime_get_real
  .offset:     1177701795305563440 nsecs
active timers:
 clock 1:
  .index:      1
  .resolution: 1 nsecs
  .get_time:   ktime_get
  .offset:     0 nsecs
active timers:
 #0: <e4a79f00>, tick_sched_timer, S:01
 # expires at 249154808417850 nsecs [in 392100 nsecs]
 #1: <e4a79f00>, it_real_fn, S:01
 # expires at 249154832599897 nsecs [in 24574147 nsecs]
 #2: <e4a79f00>, hrtimer_wakeup, S:01
 # expires at 249154937316640 nsecs [in 129290890 nsecs]
 #3: <e4a79f00>, it_real_fn, S:01
 # expires at 249154940604253 nsecs [in 132578503 nsecs]
 #4: <e4a79f00>, it_real_fn, S:01
 # expires at 249156991584989 nsecs [in 2183559239 nsecs]
 #5: <e4a79f00>, hrtimer_wakeup, S:01
 # expires at 249163930201148 nsecs [in 9122175398 nsecs]
 #6: <e4a79f00>, hrtimer_wakeup, S:01
 # expires at 249163930619465 nsecs [in 9122593715 nsecs]
 #7: <e4a79f00>, it_real_fn, S:01
 # expires at 249164018722673 nsecs [in 9210696923 nsecs]
 #8: <e4a79f00>, it_real_fn, S:01
 # expires at 249164018756764 nsecs [in 9210731014 nsecs]
 #9: <e4a79f00>, hrtimer_wakeup, S:01
 # expires at 249166140491719 nsecs [in 11332465969 nsecs]
 #10: <e4a79f00>, it_real_fn, S:01
 # expires at 249168890475020 nsecs [in 14082449270 nsecs]
 #11: <e4a79f00>, it_real_fn, S:01
 # expires at 249216937518155 nsecs [in 62129492405 nsecs]
 #12: <e4a79f00>, it_real_fn, S:01
 # expires at 249694958542841 nsecs [in 540150517091 nsecs]
 #13: <e4a79f00>, hrtimer_wakeup, S:01
 # expires at 252071939585424 nsecs [in 2917131559674 nsecs]
 #14: <e4a79f00>, it_real_fn, S:01
 # expires at 277954353421786 nsecs [in 28799545396036 nsecs]
  .expires_next   : 249154808417850 nsecs
  .hres_active    : 1
  .nr_events      : 12571303
  .nohz_mode      : 2
  .idle_tick      : 249154808417850 nsecs
  .tick_stopped   : 0
  .idle_jiffies   : 74656449
  .idle_calls     : 31252991
  .idle_sleeps    : 18916982
  .idle_entrytime : 249154806452801 nsecs
  .idle_sleeptime : 202805663229475 nsecs
  .last_jiffies   : 74656449
  .next_jiffies   : 74656452
  .idle_expires   : 249154815084516 nsecs
jiffies: 74656449

cpu: 1
 clock 0:
  .index:      0
  .resolution: 1 nsecs
  .get_time:   ktime_get_real
  .offset:     1177701795305563440 nsecs
active timers:
 clock 1:
  .index:      1
  .resolution: 1 nsecs
  .get_time:   ktime_get
  .offset:     0 nsecs
active timers:
 #0: <e4a79f00>, tick_sched_timer, S:01
 # expires at 249154808417850 nsecs [in 392100 nsecs]
 #1: <e4a79f00>, it_real_fn, S:01
 # expires at 249154824005495 nsecs [in 15979745 nsecs]
 #2: <e4a79f00>, hrtimer_wakeup, S:01
 # expires at 249154876721584 nsecs [in 68695834 nsecs]
 #3: <e4a79f00>, hrtimer_wakeup, S:01
 # expires at 249154876724658 nsecs [in 68698908 nsecs]
 #4: <e4a79f00>, it_real_fn, S:01
 # expires at 249156991445550 nsecs [in 2183419800 nsecs]
 #5: <e4a79f00>, hrtimer_wakeup, S:01
 # expires at 249158033258177 nsecs [in 3225232427 nsecs]
 #6: <e4a79f00>, it_real_fn, S:01
 # expires at 249158937910855 nsecs [in 4129885105 nsecs]
 #7: <e4a79f00>, hrtimer_wakeup, S:01
 # expires at 249160645185907 nsecs [in 5837160157 nsecs]
 #8: <e4a79f00>, hrtimer_wakeup, S:01
 # expires at 249288273241617 nsecs [in 133465215867 nsecs]
 #9: <e4a79f00>, it_real_fn, S:01
 # expires at 249688052597900 nsecs [in 533244572150 nsecs]
 #10: <e4a79f00>, hrtimer_wakeup, S:01
 # expires at 250127175002655 nsecs [in 972366976905 nsecs]
 #11: <e4a79f00>, hrtimer_wakeup, S:01
 # expires at 252087970262178 nsecs [in 2933162236428 nsecs]
  .expires_next   : 249154808417850 nsecs
  .hres_active    : 1
  .nr_events      : 13107829
  .nohz_mode      : 2
  .idle_tick      : 249154805084517 nsecs
  .tick_stopped   : 0
  .idle_jiffies   : 74656448
  .idle_calls     : 27583722
  .idle_sleeps    : 11208166
  .idle_entrytime : 249154805632934 nsecs
  .idle_sleeptime : 197905845372598 nsecs
  .last_jiffies   : 74656449
  .next_jiffies   : 74656450
  .idle_expires   : 249154935084504 nsecs
jiffies: 74656449


Tick Device: mode:     1
Clock Event Device: pit
 max_delta_ns:   27461866
 min_delta_ns:   12571
 mult:           5124677
 shift:          32
 mode:           3
 next_event:     9223372036854775807 nsecs
 set_next_event: pit_next_event
 set_mode:       init_pit_timer
 event_handler:  tick_handle_oneshot_broadcast
tick_broadcast_mask: 00000000
tick_broadcast_oneshot_mask: 00000000


Tick Device: mode:     1
Clock Event Device: lapic
 max_delta_ns:   503300116
 min_delta_ns:   1000
 mult:           71585107
 shift:          32
 mode:           3
 next_event:     249154808417850 nsecs
 set_next_event: lapic_next_event
 set_mode:       lapic_timer_setup
 event_handler:  hrtimer_interrupt

Tick Device: mode:     1
Clock Event Device: lapic
 max_delta_ns:   503300116
 min_delta_ns:   1000
 mult:           71585107
 shift:          32
 mode:           3
 next_event:     249154808417850 nsecs
 set_next_event: lapic_next_event
 set_mode:       lapic_timer_setup
 event_handler:  hrtimer_interrupt

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

* Re: Linux 2.6.21: pmtmr losing time
  2007-04-30 16:39   ` Joerg Sommrey
@ 2007-04-30 21:38     ` Thomas Gleixner
  2007-05-01  7:36       ` Joerg Sommrey
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas Gleixner @ 2007-04-30 21:38 UTC (permalink / raw)
  To: Joerg Sommrey; +Cc: Linux kernel mailing list

On Mon, 2007-04-30 at 18:39 +0200, Joerg Sommrey wrote:
> Here it is.  Maybe this problem is related to the usage of the
> "experimental" amd76x_pm module?

Can you please verify what happens w/o that module ?

Thanks,

	tglx



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

* Re: Linux 2.6.21: pmtmr losing time
  2007-04-30 21:38     ` Thomas Gleixner
@ 2007-05-01  7:36       ` Joerg Sommrey
  2007-05-14 16:20         ` Joerg Sommrey
  0 siblings, 1 reply; 6+ messages in thread
From: Joerg Sommrey @ 2007-05-01  7:36 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Linux kernel mailing list

On Mon, Apr 30, 2007 at 11:38:34PM +0200, Thomas Gleixner wrote:
> On Mon, 2007-04-30 at 18:39 +0200, Joerg Sommrey wrote:
> > Here it is.  Maybe this problem is related to the usage of the
> > "experimental" amd76x_pm module?
> 
> Can you please verify what happens w/o that module ?
> 
After rebooting the problem vanished for now.  It first appeared after
an uptime of about 3 days.  I'll wait a few days.  If it shows
again, then I'll check without amd76x_pm.

-jo

> Thanks,
> 
> 	tglx
> 
> 

-- 
-rw-r--r-- 1 jo users 62 2007-05-01 01:11 /home/jo/.signature

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

* Re: Linux 2.6.21: pmtmr losing time
  2007-05-01  7:36       ` Joerg Sommrey
@ 2007-05-14 16:20         ` Joerg Sommrey
  0 siblings, 0 replies; 6+ messages in thread
From: Joerg Sommrey @ 2007-05-14 16:20 UTC (permalink / raw)
  To: Thomas Gleixner, Linux kernel mailing list

On Tue, May 01, 2007 at 09:36:24AM +0200, Joerg Sommrey wrote:
> On Mon, Apr 30, 2007 at 11:38:34PM +0200, Thomas Gleixner wrote:
> > On Mon, 2007-04-30 at 18:39 +0200, Joerg Sommrey wrote:
> > > Here it is.  Maybe this problem is related to the usage of the
> > > "experimental" amd76x_pm module?
> > 
> > Can you please verify what happens w/o that module ?
> > 
> After rebooting the problem vanished for now.  It first appeared after
> an uptime of about 3 days.  I'll wait a few days.  If it shows
> again, then I'll check without amd76x_pm.

It really looks like amd76x_pm is causing the time loss.  Sadly, I have
no idea how to avoid this.  What happens when the pm-timer wraps around
while the processors are in C3 sleep state?  How is this wrap detected
at all?  Is there anything I could put into amd76x_pm?  It's no problem
detecting a timer wrap there.

-jo

-- 
-rw-r--r-- 1 jo users 62 2007-05-13 21:55 /home/jo/.signature

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

end of thread, other threads:[~2007-05-14 16:20 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-04-30 12:52 Linux 2.6.21: pmtmr losing time Joerg Sommrey
2007-04-30 16:23 ` Thomas Gleixner
2007-04-30 16:39   ` Joerg Sommrey
2007-04-30 21:38     ` Thomas Gleixner
2007-05-01  7:36       ` Joerg Sommrey
2007-05-14 16:20         ` Joerg Sommrey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox