Re: System clock speed too high - 2.6.3 kernel

Re: System clock speed too high - 2.6.3 kernel

[Joris van Rantwijk]

Hello,

On Fri, 26 Mar 2004, Praedor Atrebates wrote:
> I have Mandrake 10.0, kernel-2.6.3-7mdk installed, on an IBM Thinkpad 1412
> laptop, celeron 366, 512MB RAM.  I am finding that my system clock is ticking
> away at a rate of about 3:1 vs reality, ie, I count ~3 seconds on the system
> clock for every 1 real second.  I am running ntpd but this is unable to keep
> up with the rate of system clock passage.

I have the same problem with kernel 2.6.6, only in my case the speed is
exactly doubled (not 3:1). Saying "clock=tsc" at boot time solves this
perfectly.

My mainboard is Asus P5A (4 years old) with ALi M1541 chipset.
Linux detects a PM-Timer at port 0xec08. I measured the counting rate
of this port (while safely running with clock=tsc) and it comes out at
about 7159155 ticks per second. The rate expected by
arch/i386/kernel/timer/timer_pm.c is 3579545 ticks per second, so this
explains the double speed very nicely.

Perhaps this should be documented in the kernel config info.
If there are many systems with this problem, then calibrating the PM timer
against the PIT timer at boot time (possibly rejecting invalid rates)
might be an option.

Bye,
  Joris.

Some information from dmesg:
ACPI: RSDP (v000 ASUS                                      ) @ 0x000f81d0
ACPI: RSDT (v001 ASUS   P5A      0x58582e32 MSFT 0x31313031) @ 0x07ffc000
ACPI: FADT (v001 ASUS   P5A      0x58582e32 MSFT 0x31313031) @ 0x07ffc080
ACPI: BOOT (v001 ASUS   P5A      0x58582e32 MSFT 0x31313031) @ 0x07ffc040
ACPI: DSDT (v001   ASUS P5A      0x00001000 MSFT 0x01000001) @ 0x00000000
ACPI: PM-Timer IO Port: 0xec08

Some information from lspci:
00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 04)
00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 04)
00:02.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03)
00:03.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU
00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV] (rev c3)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c1)
01:00.0 VGA compatible controller: nVidia Corporation Riva TnT [NV04] (rev 04)

Re: System clock speed too high - 2.6.3 kernel

[john stultz]

On Tue, 2004-05-25 at 02:22, Joris van Rantwijk wrote:
> On Fri, 26 Mar 2004, Praedor Atrebates wrote:
> > I have Mandrake 10.0, kernel-2.6.3-7mdk installed, on an IBM Thinkpad 1412
> > laptop, celeron 366, 512MB RAM.  I am finding that my system clock is ticking
> > away at a rate of about 3:1 vs reality, ie, I count ~3 seconds on the system
> > clock for every 1 real second.  I am running ntpd but this is unable to keep
> > up with the rate of system clock passage.
> 
> I have the same problem with kernel 2.6.6, only in my case the speed is
> exactly doubled (not 3:1). Saying "clock=tsc" at boot time solves this
> perfectly.
> 
> My mainboard is Asus P5A (4 years old) with ALi M1541 chipset.
> Linux detects a PM-Timer at port 0xec08. I measured the counting rate
> of this port (while safely running with clock=tsc) and it comes out at
> about 7159155 ticks per second. The rate expected by
> arch/i386/kernel/timer/timer_pm.c is 3579545 ticks per second, so this
> explains the double speed very nicely.
> 
> Perhaps this should be documented in the kernel config info.
> If there are many systems with this problem, then calibrating the PM timer
> against the PIT timer at boot time (possibly rejecting invalid rates)
> might be an option.

Check out bugme bug #2375. Some systems have ACPI PM timers that run too
fast. Running w/ "clock=tsc" is the proper workaround, but we need to
blacklist such systems from using it. If you could add dmidecode output
to the bug, I'll add your system to the list. 

http://bugme.osdl.org/show_bug.cgi?id=2375

thanks
-john

Re: System clock speed too high - 2.6.3 kernel

[john stultz]

On Tue, 2004-05-25 at 02:22, Joris van Rantwijk wrote:
> Perhaps this should be documented in the kernel config info.
> If there are many systems with this problem, then calibrating the PM timer
> against the PIT timer at boot time (possibly rejecting invalid rates)
> might be an option.

Also your point above is a good one. We probably should do a sanity
check to make sure we're getting a reasonable frequency (however then
we'll probably start having troubles w/ systems that have broken PITs ;)

I'll put it on my todo list, but if you'd like to take a swing at ti and
beat me to the implementation, I wouldn't complain.

thanks
-john

Re: System clock speed too high - 2.6.3 kernel

[Joris van Rantwijk]

On Tue, 25 May 2004, john stultz wrote:
> On Tue, 2004-05-25 at 02:22, Joris van Rantwijk wrote:
> > If there are many systems with this problem, then calibrating the PM timer
> > against the PIT timer at boot time (possibly rejecting invalid rates)
> > might be an option.

> I'll put it on my todo list, but if you'd like to take a swing at ti and
> beat me to the implementation, I wouldn't complain.

Sounds fair. I tried something and it even seems to work here.
My dmesg now says:
  PM-Timer running at invalid rate: 199% of normal - aborting.
  Detected 400.816 MHz processor.
  Using tsc for high-res timesource

Hmm, I think I'm enjoying this :-)
My patch is included below and also submitted at the Kernel Bugzilla
thing. I would appreciate it if someone else could also test it a bit.

Yesterday, I ran into a (hopefully) completely seperate issue with the
timer. This happened before I even started messing with the kernel and
while running with "clock=tsc". The kernel suddenly logged:
  Losing too many ticks!
  TSC cannot be used as a timesource
   ...
  Falling back to a sane timesource now.

And from that point on my system clock was running at about one third of
normal speed. The fallback timesource is just the PIT timer, so it seems
that my PIT had spontaneously dropped speed (thereby also causing the lost
ticks). Anyone else seen this before ?

Bye,
  Joris.

Patch: Verify PMTMR rate against PIT Ch2 at boot time before using it
Against: linux-2.6.6

--- linux-2.6.6/arch/i386/kernel/timers/timer_pm.orig.c	Sun Apr  4 05:36:18 2004
+++ linux-2.6.6/arch/i386/kernel/timers/timer_pm.c	Thu May 27 00:11:22 2004
@@ -19,10 +19,18 @@
 #include <asm/timer.h>
 #include <asm/smp.h>
 #include <asm/io.h>
 #include <asm/arch_hooks.h>

+#include <linux/timex.h>
+#include "mach_timer.h"
+
+/* Number of PMTMR ticks expected during calibration run */
+#define PMTMR_TICKS_PER_SEC 3579545
+#define PMTMR_EXPECTED_RATE \
+  ((CALIBRATE_LATCH * (PMTMR_TICKS_PER_SEC >> 10)) / (CLOCK_TICK_RATE>>10))
+

 /* The I/O port the PMTMR resides at.
  * The location is detected during setup_arch(),
  * in arch/i386/acpi/boot.c */
 u32 pmtmr_ioport = 0;
@@ -55,10 +63,37 @@

 	/* mask the output to 24 bits */
 	return v2 & ACPI_PM_MASK;
 }

+
+/*
+ * Some boards have the PMTMR running way too fast. We check
+ * the PMTMR rate against PIT channel 2 to catch these cases.
+ */
+static int verify_pmtmr_rate(void)
+{
+	u32 value1, value2;
+	unsigned long count, delta;
+
+	mach_prepare_counter();
+	value1 = read_pmtmr();
+	mach_countup(&count);
+	value2 = read_pmtmr();
+	delta = (value2 - value1) & ACPI_PM_MASK;
+
+	/* Check that the PMTMR delta is within 5% of what we expect */
+	if (delta < (PMTMR_EXPECTED_RATE * 19) / 20 ||
+	    delta > (PMTMR_EXPECTED_RATE * 21) / 20) {
+		printk(KERN_INFO "PM-Timer running at invalid rate: %lu%% of normal - aborting.\n", 100UL * delta / PMTMR_EXPECTED_RATE);
+		return -1;
+	}
+
+	return 0;
+}
+
+
 static int init_pmtmr(char* override)
 {
 	u32 value1, value2;
 	unsigned int i;

@@ -87,10 +122,13 @@
 	}
 	printk(KERN_INFO "PM-Timer had no reasonable result: 0x%#x - aborting.\n", value1);
 	return -ENODEV;

 pm_good:
+	if (verify_pmtmr_rate() != 0)
+		return -ENODEV;
+
 	init_cpu_khz();
 	return 0;
 }

 static inline u32 cyc2us(u32 cycles)

Re: System clock speed too high - 2.6.3 kernel

[john stultz]

On Wed, 2004-05-26 at 15:43, Joris van Rantwijk wrote:
> On Tue, 25 May 2004, john stultz wrote:
> > On Tue, 2004-05-25 at 02:22, Joris van Rantwijk wrote:
> > > If there are many systems with this problem, then calibrating the PM timer
> > > against the PIT timer at boot time (possibly rejecting invalid rates)
> > > might be an option.
> 
> > I'll put it on my todo list, but if you'd like to take a swing at ti and
> > beat me to the implementation, I wouldn't complain.
> 
> Sounds fair. I tried something and it even seems to work here.
> My dmesg now says:
>   PM-Timer running at invalid rate: 199% of normal - aborting.
>   Detected 400.816 MHz processor.
>   Using tsc for high-res timesource
> 
> Hmm, I think I'm enjoying this :-)
> My patch is included below and also submitted at the Kernel Bugzilla
> thing. I would appreciate it if someone else could also test it a bit.

As I said in the bugzilla bug, it looks good to me. I'm going to test it
on my box to make sure it works properly on normal systems, so I'll send
you the results. 

> Yesterday, I ran into a (hopefully) completely seperate issue with the
> timer. This happened before I even started messing with the kernel and
> while running with "clock=tsc". The kernel suddenly logged:
>   Losing too many ticks!
>   TSC cannot be used as a timesource
>    ...
>   Falling back to a sane timesource now.
> 
> And from that point on my system clock was running at about one third of
> normal speed. The fallback timesource is just the PIT timer, so it seems
> that my PIT had spontaneously dropped speed (thereby also causing the lost
> ticks). Anyone else seen this before ?

I've seen that occasionally, but normally due to cpufreq changes. Any
clue what else was happening on your system when it occurred? (heavy
disk load, etc?)

thanks
-john

[PATCH] 2.6.6 Validate PM-Timer rate at boot time

[Joris van Rantwijk]

The patch below adds a check to the PM-Timer initialization code.
It validates the PM-Timer rate against PIT channel 2 and rejects
the PM-Timer if its rate is not withing 5% of the expected number.

Rationale:
The PMTMR timers of certain (older) mainboards are running at invalid
rates, often much faster than the rate expected by the PM-Timer code.
This causes the system clock to run much too fast.
See also http://bugme.osdl.org/show_bug.cgi?id=2375

Possible workarounds are disabling the PM-Timer in the kernel config
or disabling the PM-Timer at boot time through the "clock=tsc" parameter.
However, we believe it is more user friendly to automatically validate
the PM-Timer rate at boot time before using it as the system time source.

Patch is against linux 2.6.6.
Tested by me (with broken timer) and John Stultz (with good timer)
and believed to be ok.
Please consider applying.

Bye,
  Joris.

--- linux-2.6.6/arch/i386/kernel/timers/timer_pm.orig.c	Sun Apr  4 05:36:18 2004
+++ linux-2.6.6/arch/i386/kernel/timers/timer_pm.c	Thu May 27 00:11:22 2004
@@ -19,10 +19,18 @@
 #include <asm/timer.h>
 #include <asm/smp.h>
 #include <asm/io.h>
 #include <asm/arch_hooks.h>

+#include <linux/timex.h>
+#include "mach_timer.h"
+
+/* Number of PMTMR ticks expected during calibration run */
+#define PMTMR_TICKS_PER_SEC 3579545
+#define PMTMR_EXPECTED_RATE \
+  ((CALIBRATE_LATCH * (PMTMR_TICKS_PER_SEC >> 10)) / (CLOCK_TICK_RATE>>10))
+

 /* The I/O port the PMTMR resides at.
  * The location is detected during setup_arch(),
  * in arch/i386/acpi/boot.c */
 u32 pmtmr_ioport = 0;
@@ -55,10 +63,37 @@

 	/* mask the output to 24 bits */
 	return v2 & ACPI_PM_MASK;
 }

+
+/*
+ * Some boards have the PMTMR running way too fast. We check
+ * the PMTMR rate against PIT channel 2 to catch these cases.
+ */
+static int verify_pmtmr_rate(void)
+{
+	u32 value1, value2;
+	unsigned long count, delta;
+
+	mach_prepare_counter();
+	value1 = read_pmtmr();
+	mach_countup(&count);
+	value2 = read_pmtmr();
+	delta = (value2 - value1) & ACPI_PM_MASK;
+
+	/* Check that the PMTMR delta is within 5% of what we expect */
+	if (delta < (PMTMR_EXPECTED_RATE * 19) / 20 ||
+	    delta > (PMTMR_EXPECTED_RATE * 21) / 20) {
+		printk(KERN_INFO "PM-Timer running at invalid rate: %lu%% of normal - aborting.\n", 100UL * delta / PMTMR_EXPECTED_RATE);
+		return -1;
+	}
+
+	return 0;
+}
+
+
 static int init_pmtmr(char* override)
 {
 	u32 value1, value2;
 	unsigned int i;

@@ -87,10 +122,13 @@
 	}
 	printk(KERN_INFO "PM-Timer had no reasonable result: 0x%#x - aborting.\n", value1);
 	return -ENODEV;

 pm_good:
+	if (verify_pmtmr_rate() != 0)
+		return -ENODEV;
+
 	init_cpu_khz();
 	return 0;
 }

 static inline u32 cyc2us(u32 cycles)

Re: System clock speed too high - 2.6.3 kernel

[Bill Davidsen]

Joris van Rantwijk wrote:
> On Tue, 25 May 2004, john stultz wrote:
> 
>>On Tue, 2004-05-25 at 02:22, Joris van Rantwijk wrote:
>>
>>>If there are many systems with this problem, then calibrating the PM timer
>>>against the PIT timer at boot time (possibly rejecting invalid rates)
>>>might be an option.
> 
> 
>>I'll put it on my todo list, but if you'd like to take a swing at ti and
>>beat me to the implementation, I wouldn't complain.
> 
> 
> Sounds fair. I tried something and it even seems to work here.
> My dmesg now says:
>   PM-Timer running at invalid rate: 199% of normal - aborting.
>   Detected 400.816 MHz processor.
>   Using tsc for high-res timesource
> 
> Hmm, I think I'm enjoying this :-)
> My patch is included below and also submitted at the Kernel Bugzilla
> thing. I would appreciate it if someone else could also test it a bit.
> 
> Yesterday, I ran into a (hopefully) completely seperate issue with the
> timer. This happened before I even started messing with the kernel and
> while running with "clock=tsc". The kernel suddenly logged:
>   Losing too many ticks!
>   TSC cannot be used as a timesource
>    ...
>   Falling back to a sane timesource now.
> 

Have to say that since adding clock=tsc my test systems are all keeping 
perfect time (ntpd running) which has not been the case since I started 
using test kernels about 2.5.38.

You do seem to have an issue with the pit.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

System clock speed too high - 2.6.3 kernel

[Praedor Atrebates]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In doing a web search on system clock speeds being too high, I found entries 
describing exactly what I am experiencing in the linux-kernel list archives, 
but have not yet found a resolution.

I have Mandrake 10.0, kernel-2.6.3-7mdk installed, on an IBM Thinkpad 1412 
laptop, celeron 366, 512MB RAM.  I am finding that my system clock is ticking 
away at a rate of about 3:1 vs reality, ie, I count ~3 seconds on the system 
clock for every 1 real second.  I am running ntpd but this is unable to keep 
up with the rate of system clock passage.  

I had to slow my keyboard repeat rate _way_ down in order to be able to type 
at all as well.   The system is limited, in that I have no way to alter the 
actual system clock (in bios at any rate).  The CPU is properly identified as 
a celeron 366.  

Does anyone have any enlightenment, or a fix, to offer?  The exact same 
software setup on a desktop system, Athlon XP2700+, has no such problems.

praedor
- -- 
"George W. Bush is a deserter, an election thief, a drunk driver, a WMD 
liar and a functional illiterate. And he poops his pants." 
- --Barbara Bush, his mother
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAZITKSTapoRk9vv8RAkxyAJ45KBKN7ngdNX6qTOwSBIxEs7rfcACgl8e0
0lKo+bfaSHPcNpA+36WGCrE=
=ZdjK
-----END PGP SIGNATURE-----

Re: System clock speed too high - 2.6.3 kernel

[john stultz]

On Fri, 2004-03-26 at 11:30, Praedor Atrebates wrote:
> In doing a web search on system clock speeds being too high, I found entries 
> describing exactly what I am experiencing in the linux-kernel list archives, 
> but have not yet found a resolution.
> 
> I have Mandrake 10.0, kernel-2.6.3-7mdk installed, on an IBM Thinkpad 1412 
> laptop, celeron 366, 512MB RAM.  I am finding that my system clock is ticking 
> away at a rate of about 3:1 vs reality, ie, I count ~3 seconds on the system 
> clock for every 1 real second.  I am running ntpd but this is unable to keep 
> up with the rate of system clock passage.  
> 
> I had to slow my keyboard repeat rate _way_ down in order to be able to type 
> at all as well.   The system is limited, in that I have no way to alter the 
> actual system clock (in bios at any rate).  The CPU is properly identified as 
> a celeron 366.  
> 
> Does anyone have any enlightenment, or a fix, to offer?  The exact same 
> software setup on a desktop system, Athlon XP2700+, has no such problems.

Could you please send me dmesg output for this system?

Does booting w/ "clock=pit" help?

thanks
-john

Re: System clock speed too high - 2.6.3 kernel

[Praedor Atrebates]

On Friday 26 March 2004 04:22 pm, john stultz held forth thus:
> On Fri, 2004-03-26 at 11:30, Praedor Atrebates wrote:
> > In doing a web search on system clock speeds being too high, I found
> > entries describing exactly what I am experiencing in the linux-kernel
> > list archives, but have not yet found a resolution.
[...]
> > Does anyone have any enlightenment, or a fix, to offer?  The exact same
> > software setup on a desktop system, Athlon XP2700+, has no such problems.
>
> Could you please send me dmesg output for this system?
>
> Does booting w/ "clock=pit" help?

Thank you, this did fix the problem.  Now I have to set the type-matic setting 
up because it is so sluggish.  

What is clock=pit doing?  What is behind this accelerated clock?

praedor
-- 
"George W. Bush is a deserter, an election thief, a drunk driver, a WMD 
liar and a functional illiterate. And he poops his pants." 
--Barbara Bush, his mother

Re: System clock speed too high - 2.6.3 kernel

[john stultz]

On Fri, 2004-03-26 at 13:54, Praedor Atrebates wrote:
> On Friday 26 March 2004 04:22 pm, john stultz held forth thus:
> > On Fri, 2004-03-26 at 11:30, Praedor Atrebates wrote:
> > > In doing a web search on system clock speeds being too high, I found
> > > entries describing exactly what I am experiencing in the linux-kernel
> > > list archives, but have not yet found a resolution.
> [...]
> > > Does anyone have any enlightenment, or a fix, to offer?  The exact same
> > > software setup on a desktop system, Athlon XP2700+, has no such problems.
> >
> > Could you please send me dmesg output for this system?
> >
> > Does booting w/ "clock=pit" help?
> 
> Thank you, this did fix the problem.  Now I have to set the type-matic setting 
> up because it is so sluggish.  
> 
> What is clock=pit doing?  What is behind this accelerated clock?

This is just manually overriding the automatic time source selection.
You're using the PIT (programmable interval timer) over what was being
automatically selected (according the to the dmesg you sent me, the
pmtmr or ACPI PM timer) by your kernel config. 

As clock=pit seemed to solve the problem, it looks like its a ACPI PM
issue. 

thanks
-john

Re: System clock speed too high - 2.6.3 kernel

[john stultz]

On Fri, 2004-03-26 at 15:00, Praedor Atrebates wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Friday 26 March 2004 04:22 pm, john stultz held forth thus:
> > On Fri, 2004-03-26 at 11:30, Praedor Atrebates wrote:
> > > In doing a web search on system clock speeds being too high, I found
> > > entries describing exactly what I am experiencing in the linux-kernel
> > > list archives, but have not yet found a resolution.
> > >
> > > I have Mandrake 10.0, kernel-2.6.3-7mdk installed, on an IBM Thinkpad
> > > 1412 laptop, celeron 366, 512MB RAM.  I am finding that my system clock
> > > is ticking away at a rate of about 3:1 vs reality, ie, I count ~3 seconds
> [...]
> > Could you please send me dmesg output for this system?
> >
> > Does booting w/ "clock=pit" help?
> 
> Attached is the output of dmesg.  As I scanned it I see that I still have APIC 
> disabled in Bios.  I'll try enabling it and, if that doesn't help, then I 
> will try the "clock=pit" switch.

I noticed in the dmesg you sent me that you're using the ACPI PM time
source. There has just recently been a bug opened for a very similar
issue (see http://bugme.osdl.org/show_bug.cgi?id=2375 ). 

First of all, scratch trying "clock=pit" and test booting w/
"clock=tsc". If that resolves the issue, disable ACPI PM timesource
support (under the ACPI menu) in your kerel and that should fix you for
the short term. 

As for the long term, I'm curious if this is a BIOS/Hardware quirk on
some systems or if there is just something we missed. 

Dominik/Len: Any clue on this?

thanks
-john

Re: System clock speed too high - 2.6.3 kernel

[Praedor Atrebates]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 26 March 2004 04:57 pm, john stultz held forth thus:
> On Fri, 2004-03-26 at 15:00, Praedor Atrebates wrote:
[...]
> > On Friday 26 March 2004 04:22 pm, john stultz held forth thus:
> > > On Fri, 2004-03-26 at 11:30, Praedor Atrebates wrote:
> > > > In doing a web search on system clock speeds being too high, I found
> > > > entries describing exactly what I am experiencing in the linux-kernel
> > > > list archives, but have not yet found a resolution.
> > > >
> > > > I have Mandrake 10.0, kernel-2.6.3-7mdk installed, on an IBM Thinkpad
> > > > 1412 laptop, celeron 366, 512MB RAM.  I am finding that my system
> > > > clock is ticking away at a rate of about 3:1 vs reality, ie, I count
> > > > ~3 seconds
[...]
> > > Does booting w/ "clock=pit" help?
[...]
> I noticed in the dmesg you sent me that you're using the ACPI PM time
> source. There has just recently been a bug opened for a very similar
> issue (see http://bugme.osdl.org/show_bug.cgi?id=2375 ).
>
> First of all, scratch trying "clock=pit" and test booting w/
> "clock=tsc". If that resolves the issue, disable ACPI PM timesource
> support (under the ACPI menu) in your kerel and that should fix you for
> the short term.

Hmpf.  I'll try the clock=tsc switch next.  I did boot using the clock=pit 
switch and the clock was normal...but I had also changed the append statement 
acpi=on to acpi=off as well.  I'll set it back to "on" and try "clock=tsc" in 
combination.

My bios is very limited.  This is a rather old laptop and there is just not a 
lot I can do.  I'll check it one more time as I reboot.

Thanks for the help.

praedor

- -- 
"George W. Bush is a deserter, an election thief, a drunk driver, a WMD 
liar and a functional illiterate. And he poops his pants." 
- --Barbara Bush, his mother
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAZKlDSTapoRk9vv8RAvmWAJ94jPIPaSwdrtOoNkwKpz4eKokBjwCglolS
ih1YhCpj706DtrVFt7Y42bs=
=oW8n
-----END PGP SIGNATURE-----

Re: System clock speed too high - 2.6.3 kernel

[Praedor Atrebates]

On Friday 26 March 2004 04:57 pm, john stultz held forth thus:
[...]
> I noticed in the dmesg you sent me that you're using the ACPI PM time
> source. There has just recently been a bug opened for a very similar
> issue (see http://bugme.osdl.org/show_bug.cgi?id=2375 ).
>
> First of all, scratch trying "clock=pit" and test booting w/
> "clock=tsc". If that resolves the issue, disable ACPI PM timesource
> support (under the ACPI menu) in your kerel and that should fix you for
> the short term.
[...]

OK.  Re-enabling ACPI in the append statement and using "clock=tsc" works.  
The clock is as it should be.

I took a good look at the bios menus and there just isn't really anything 
there I can fiddle with:

ACPI OS Fast Post.........................[enable/disable]
Silent boot.....................................[enable/disable]
PnP OS..........................................[enable/disable]

That's it.  

Thanks for the help.

praedor

-- 
"George W. Bush is a deserter, an election thief, a drunk driver, a WMD 
liar and a functional illiterate. And he poops his pants." 
--Barbara Bush, his mother

Re: System clock speed too high - 2.6.3 kernel

[john stultz]

On Fri, 2004-03-26 at 15:00, Praedor Atrebates wrote:
> On Friday 26 March 2004 04:22 pm, john stultz held forth thus:
> > On Fri, 2004-03-26 at 11:30, Praedor Atrebates wrote:
> > > In doing a web search on system clock speeds being too high, I found
> > > entries describing exactly what I am experiencing in the linux-kernel
> > > list archives, but have not yet found a resolution.
> > >
> > > I have Mandrake 10.0, kernel-2.6.3-7mdk installed, on an IBM Thinkpad
> > > 1412 laptop, celeron 366, 512MB RAM.  I am finding that my system clock
> > > is ticking away at a rate of about 3:1 vs reality, ie, I count ~3 seconds
> [...]
> > Could you please send me dmesg output for this system?
> >
> Attached is the output of dmesg.  

You mentioned that your system is an older laptop, and you're setting
"acpi=on" in your boot arguments. What happens when you omit "acpi=on"?
Do you get a message saying something to the effect of your system being
too old for ACPI? Does everything still work as it ought?

I'm still working on this one. 
See http://bugme.osdl.org/show_bug.cgi?id=2375 for more details.

thanks
-john

Re: System clock speed too high - 2.6.3 kernel

[Dominik Brodowski]

On Tue, Mar 30, 2004 at 07:25:39AM -0800, john stultz wrote:
> On Fri, 2004-03-26 at 15:00, Praedor Atrebates wrote:
> > On Friday 26 March 2004 04:22 pm, john stultz held forth thus:
> > > On Fri, 2004-03-26 at 11:30, Praedor Atrebates wrote:
> > > > In doing a web search on system clock speeds being too high, I found
> > > > entries describing exactly what I am experiencing in the linux-kernel
> > > > list archives, but have not yet found a resolution.
> > > >
> > > > I have Mandrake 10.0, kernel-2.6.3-7mdk installed, on an IBM Thinkpad
> > > > 1412 laptop, celeron 366, 512MB RAM.  I am finding that my system clock
> > > > is ticking away at a rate of about 3:1 vs reality, ie, I count ~3 seconds
> > [...]
> > > Could you please send me dmesg output for this system?
> > >
> > Attached is the output of dmesg.  
> 
> You mentioned that your system is an older laptop, and you're setting
> "acpi=on" in your boot arguments. What happens when you omit "acpi=on"?
> Do you get a message saying something to the effect of your system being
> too old for ACPI? Does everything still work as it ought?

Hm, could you please verify that ACPI throttling and cpufreq is _disabled_
when you do this check? For throttling, please do

echo 1 > /proc/acpi/processor/./throttling
echo 0 > /proc/acpi/processor/./throttling

[just echo'ing 0 is a noop if ACPI thinks it's at T0... and we want to force
T0].

	Dominik

Re: System clock speed too high - 2.6.3 kernel

[George Anzinger]

Praedor Atrebates wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> In doing a web search on system clock speeds being too high, I found entries 
> describing exactly what I am experiencing in the linux-kernel list archives, 
> but have not yet found a resolution.
> 
> I have Mandrake 10.0, kernel-2.6.3-7mdk installed, on an IBM Thinkpad 1412 
> laptop, celeron 366, 512MB RAM.  I am finding that my system clock is ticking 
> away at a rate of about 3:1 vs reality, ie, I count ~3 seconds on the system 
> clock for every 1 real second.  I am running ntpd but this is unable to keep 
> up with the rate of system clock passage.  
> 
> I had to slow my keyboard repeat rate _way_ down in order to be able to type 
> at all as well.   The system is limited, in that I have no way to alter the 
> actual system clock (in bios at any rate).  The CPU is properly identified as 
> a celeron 366.  
> 
> Does anyone have any enlightenment, or a fix, to offer?  The exact same 
> software setup on a desktop system, Athlon XP2700+, has no such problems.

Try this in the boot command line "clock=pmtmr".  If that fails, then try 
"clock=pit".

-g
> 
> praedor
> - -- 
> "George W. Bush is a deserter, an election thief, a drunk driver, a WMD 
> liar and a functional illiterate. And he poops his pants." 
> - --Barbara Bush, his mother
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFAZITKSTapoRk9vv8RAkxyAJ45KBKN7ngdNX6qTOwSBIxEs7rfcACgl8e0
> 0lKo+bfaSHPcNpA+36WGCrE=
> =ZdjK
> -----END PGP SIGNATURE-----
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

Re: System clock speed too high - 2.6.3 kernel

[Praedor Atrebates]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 26 March 2004 04:46 pm, George Anzinger held forth thus:
> Praedor Atrebates wrote:
> > In doing a web search on system clock speeds being too high, I found
> > entries describing exactly what I am experiencing in the linux-kernel
> > list archives, but have not yet found a resolution.
> >
> > I have Mandrake 10.0, kernel-2.6.3-7mdk installed, on an IBM Thinkpad
> > 1412 laptop, celeron 366, 512MB RAM.  I am finding that my system clock
> > is ticking away at a rate of about 3:1 vs reality, ie, I count ~3 seconds
> > on the system clock for every 1 real second.  I am running ntpd but this
> > is unable to keep up with the rate of system clock passage.
[...]
> Try this in the boot command line "clock=pmtmr".  If that fails, then try
> "clock=pit".

What is the difference between the two settings?  I used the latter and it 
worked (didn't try "clock=pmtmr").

praedor

- -- 
"George W. Bush is a deserter, an election thief, a drunk driver, a WMD 
liar and a functional illiterate. And he poops his pants." 
- --Barbara Bush, his mother
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAZKdCSTapoRk9vv8RAhPDAKDTnTfPABRkJxj0Gy/14d2SsiLL8wCg5r1+
XoUhJcQbDzshPIT++0x/g9o=
=6j96
-----END PGP SIGNATURE-----

Re: System clock speed too high - 2.6.3 kernel

[George Anzinger]

Praedor Atrebates wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Friday 26 March 2004 04:46 pm, George Anzinger held forth thus:
> 
>>Praedor Atrebates wrote:
>>
>>>In doing a web search on system clock speeds being too high, I found
>>>entries describing exactly what I am experiencing in the linux-kernel
>>>list archives, but have not yet found a resolution.
>>>
>>>I have Mandrake 10.0, kernel-2.6.3-7mdk installed, on an IBM Thinkpad
>>>1412 laptop, celeron 366, 512MB RAM.  I am finding that my system clock
>>>is ticking away at a rate of about 3:1 vs reality, ie, I count ~3 seconds
>>>on the system clock for every 1 real second.  I am running ntpd but this
>>>is unable to keep up with the rate of system clock passage.
> 
> [...]
> 
>>Try this in the boot command line "clock=pmtmr".  If that fails, then try
>>"clock=pit".
> 
> 
> What is the difference between the two settings?  I used the latter and it 
> worked (didn't try "clock=pmtmr").
> 
There are three clock sources in the x86 kernel, the PIT (programmable interrupt 
timer), the TSC, and the pmtimer (power management timer).

The PIT has been in the hardware since, well, day one.  It almost always works 
and it is clocked by a special Xtal.  The down side is it is accessed with 8-bit 
I/O instructions and so is dog slow to change or look at.

The TSC (time stamp counter) is a newer thing so is not available on all 
hardware although, now, most boxes that don't have TSCs are in land fills :). 
It is accessed via a machine register.  It is usually the cpu clock and so is a 
direct indicator of the cpu speed.  The boot report of cpu speed comes from a 
comparison of the TSC and the PIT, and, in fact this comparison is used to 
calibrate the TSC so it can be used to interpolate between PIT interrupts.  So, 
even here, the PIT is still the tick generator, while the TSC is used to replace 
the reading of the PIT to interpolate between interrupts.  The down side is that 
prior to the pentium 4, the TSC frequency was exactly the processor clock and 
was subject to change to control heat and power usage in the cpu.  I.e. the TSC 
was slowed down to cool the cpu (and to save power).  This makes it an 
unreliable time source for those cpus that do this, in particular lap tops that 
are very much into saving power.

The pmtimer is part of the ACPI hardware.  It is clocked by the same xtal as the 
PIT.  It does not interrupt, so again, the PIT is the interrupt source for time 
ticks.  It has a resolution of three times the PIT (same clock, different 
divider).  It is called the power management timer as it is was designed to 
provide a stable time reference for all power states (except off, of course), so 
is not subject to the slow downs the TSC is.  The down side is that it is 
accessed with an I/O instruction and so is slow.  I have measured a 3 times 
difference in gettimeofday() on an 800MHZ PIII between the TSC and the pmtimer, 
for example.  (And this was with just one read of the pmtimer per 
gettimeofday(), were as the kernel now does three because some hardware gets it 
wrong.)

So, you may ask, if the PIT is the interrupt source, why does the pmtimer being 
off cause my clock to run fast?  It would seem that only the interpolation 
between ticks would be fast, not the whole clock.  The answer to this is the 
"lost tick" detection code.  This code uses the pmtimer or the TSC to check for 
lost ticks and adjusts the clock based on this.

Questions?
-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml