My system clock runs at approximately half speed in
linux-2.6.20, 2.6.20-git10 and 2.6.20-git11. That is, it takes about
two hours for "date" to report that one hour has elapsed. "hwclock"
returns the correct time, of course.
I do not have this problem in linuux 2.6.18.1. I will try to
narrow down the kernel version where this problem began.
The motherboard in question is an asus p4v8000-x, running a
2.8GHz Pentium 4 that has two hyperthreads, which I suspect may be the
problem. I am just guessing, but perhaps some piece of code thinks
the two hyperthreads are separate CPU's receving twice as many clock
interrupts total. I expect to try to some experimentation to check
this theory.
For what it's worth, I am running CONFIG_PREEMPT=y,
CONFIG_PREEMPT_BKL=y, CONFIG_HZ=1000.
If there is a more specific mailing list for discussing this
problem, I would be interested in knowning about it. The MAINTAINERS
file lists several components with the word "clock" in them, but I
believe that all are for drivers for hardware clocks or high
resolution timer extensions. I tried a quick search of the
linux-kernel mailing list for "clock" in the subject line, and did not
notice anything that seemed like a match to this problem.
I will post more information as I collect it, but I am posting
this bug report now in case this problem rings a bell for anyone.
Adam Richter
On Fri, 2007-02-16 at 22:28 +0800, Adam J. Richter wrote:
> My system clock runs at approximately half speed in
> linux-2.6.20, 2.6.20-git10 and 2.6.20-git11. That is, it takes about
> two hours for "date" to report that one hour has elapsed. "hwclock"
> returns the correct time, of course.
>
> I do not have this problem in linuux 2.6.18.1. I will try to
> narrow down the kernel version where this problem began.
>
> The motherboard in question is an asus p4v8000-x, running a
> 2.8GHz Pentium 4 that has two hyperthreads, which I suspect may be the
> problem. I am just guessing, but perhaps some piece of code thinks
> the two hyperthreads are separate CPU's receving twice as many clock
> interrupts total. I expect to try to some experimentation to check
> this theory.
>
> For what it's worth, I am running CONFIG_PREEMPT=y,
> CONFIG_PREEMPT_BKL=y, CONFIG_HZ=1000.
if you run,
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
it will tell you which hardware clock is being used by the kernel. You
can also run,
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
which will tell you which clocks are available on your system. You
switch clocks by echoing the name of a clock into "current_clocksource"
As an example, the following switches to the acpi_pm clocksource,
echo "acpi_pm"> /sys/devices/system/clocksource/clocksource0/current_clocksource
The hardware clock that your using could be running to slow. I would
recommend switching the hardware clock and re-check if the time is still
half speed.
Daniel
On Fri, 16 Feb 2007 08:24:54 -0800, Daniel Walker wrote:
>On Fri, 2007-02-16 at 22:28 +0800, Adam J. Richter wrote:
>> My system clock runs at approximately half speed in
>> linux-2.6.20, 2.6.20-git10 and 2.6.20-git11.
[...]
>cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
>cat /sys/devices/system/clocksource/clocksource0/available_clocksource
acpi_pm jiffies tsc
When I rebooted with "max_cpus=1", available_clocksource included a
fourth option "pit".
I have some bad news. The problem is sporadic. Here are the
logs of the tests that I have made, in the order in which I recall
making them:
2.6.20-git11 problem occurred
2.6.20-git10 problem occurred
2.6.20 problem occurred
2.6.18.1 no problem
[At this point, I made my original posting.]
2.6.20-git11 maxcpus=1 no problem
...checked current_clocksource, was tsc
2.6.18.1 no problem
...checked current_clocksource, was tsc
2.6.20-git11 no problem (this is bad!)
checked current_clocksource, was tsc
set clocksource=acpi_pm, still no problem
set clocksource=jiffies, still no problem
power cycled computer, unplugging power supply and powered down monitor
2.6.20-git11 no problem (this is bad!)
checked current_clocksource, was tsc
At first, I was very happy to see the problem disappear after
rebooting 2.6.20-git11 with "max_cpus=1", as this would tend to
indicate some mistake related to hyperthreading, but, after that I
have been unable to reproduce the problem, so I really don't know that
booting with maxcpus=1 fixed it. Perhaps the previous boot to
2.6.18.1 did.
I should also mention, that around the time that I first
noticed the problem, I observed audio stuttering under 2.6.20-git11
regularly, in intervals of perhaps 300 milliseconds, which I suspect
is a symptom of the slow system clock causing the audio driver not to
fill output buffers in time. Now, when I cannot reproduce the clock
slowdown problem, audio is playing fine under the same 2.6.20-git11
kernel.
I have observed the audio stuttering a few times in the past
week or so. The next time it happens, I'll see if the clock slowdown
has returned and I'll record and experiment with the other clock
sources.
I'll let you know when I have more useful information or mske
other progress related to this problem.
Thank you for your help!
Adam Richter