Messages in this thread | | | Date | Mon, 1 Sep 2008 22:45:05 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: Regression in 2.6.27 caused by commit bfc0f59 |
| |
On Mon, 1 Sep 2008, Larry Finger wrote: > Thomas Gleixner wrote: > > On Mon, 1 Sep 2008, Larry Finger wrote: > > > The timed sleep is as accurate as I can measure. > > > > > > I put in some test prints. The value of pm2 is zero when the else branch > > > of > > > the "if (hpet)" is entered; however, pm1 is 15768471. When we reach the > > > do_div(tsc2, tsc1) statement, tsc2 is zero, which I think means that the > > > two > > > calls to tsc_read_refs() are returning the same junk value. > > > > Ok, so the pmtimer is probably detected later as unusable and disabled. > > Please check your logs for: "PM-Timer had inconsistent results:" > > Booting 2.6.26, the dmesg output has a line that says: > > PM-Timer running at invalid rate: 200% of normal - aborting. > > Amazing that it should be exactly 200%. Why is the CPU running at half speed > when the PM-Timer rate is measured?
The kernel assumes that the PM timer frequency is normal, so it does:
read pm-timer start value, read TSC start value wait for a some time read pm-timer end value, read TSC end value
And the TSC frequency is calculated via:
TSC-End - TSC-Start TSC-Frequency = -------------------- * PM-Frequency PM-End - PM-Start
So if your PM-Timer runs at the double frequency for reasons only known to the Chip Manufacturer the kernel miscalculates the TSC frequency by factor 0.5.
Simple rule of three.
Thanks,
tglx
| |