Distribution: Hardware Environment: Notebook Maxdata Eco 3000X Processor: P4 2Gz Chipset: SIS650 Software Environment: RedHat 8.0 + kernel 2.5.70 RedHat 9.0 + kernel 2.5.72 kernels were built by gcc 3.2.3 using default .config from arch/i386 Problem Description: System time runs at least twice faster than necessary. As a result have problems with keyboard timings: very short delay before repeat mode and very fast repeat rate problems with mouse: very fast double-click speed Steps to reproduce: buld, install kernel and restart :)
We've noticed this too on an x440. It borks the system => changing prio to high. Assigning to John, since he's already working on it ;-)
ok, looking into it. This is a P4 w/o hyperthreading, correct?
So far unable to reproduce it on either a flat SMP P4 system or a 8 way x440. Sounds like a problem we were seeing w/ interrupt distribution on the x440 on 2.5.70, but that problem has been fixed since 2.5.71. Ivan: Can you attach your .config?
ok, reproduced with 2.5.72 on my T20 thinkpad when booting off the battery. when booting on AC all seems well. once booted i can plug/unplug the power and the system stays working or broken depending on how it started.
Ok, looks like the lost tick compensation code is biting us. If we calibrate_tsc() @ 150Mhz then when the system speeds up to 750Mhz every interrupt the system thinks its missed tons of ticks. Thus it tries to compensate by kicking jiffies up appropriately thus time races forward and soft timers (kbd repeat, etc) expire much faster. Booting w/ "clock=pit" will force the system to use the PIT instead of the tsc as a time source. This should solve the problem, although we need a method to detect this and fall back automatically so you don't need extra options.
Thanks John, "clock=pit" works.
Lowering the priority since there is a workaround. I'm also considering implementing an ACPI timer timer_opts that laptops can use instead of the TSC. However detecting speedstep/thermal throttling is going to be an issue regardless.
Created attachment 441 [details] linux-2.5.72_ifdef-lost-ticks_A0 Patch just sent to Andrew which #ifdef's out the TSC based lost tick compensation code. This should let speedstep users get by while a proper fix is made.
Created attachment 443 [details] linux-2.5.72_lost-tick-spst_A0test1 First shot at a patch which detects massive lost ticks caused by speedstep/cpufreq problems. When it notices 100 consecutive interrupts that detected lost ticks, it forces the time subsystem to fall back to the PIT as a time source.
I have tested patch with kernel 2.5.73. It works well!
Created attachment 458 [details] linux-2.5.73_lost-tick-spst_A0 Patch sent to Andrew for inclusion in his tree. Hopefully this should fix it for laptops. However I recieved a similar problem report on a suspected x220 that has very similar symptoms but is not a laptop/cpu frequency changing system. So not quite out of the woods yet.
Fixes have landed in 2.5.74-bk-current today.