Bug 3341

I can also reproduce this error, and have seen it in 2.6.6 and later kernels on
my HP Omnibook 6000.

I can also supply dmesg logs, if desired.

This issue seem simlar to bug #3927. 

Does booting w/ "noapic" change anything? Does booting w/ "no_timer_check" help?

> This issue seem simlar to bug #3927. 

I don't think so. in the case of #3927, the system was showing the bug in Linux.
With this bug the system shows the bug everywhere (Linux, FreeBSD, memtest86+)
even within the BIOS startup sequence.

Plus #3927 was with ATI while #3341 is with NVidia.

> Does booting w/ "noapic" change anything? Does booting w/ "no_timer_check" help?

No that makes no difference. The "noapic" flag seems to prevent the system from
booting, but still the computed CPU speed is wrong (as mentionned 3 times lower
than its actual value).

the "no_timer_check" has no effect.

It's worth noting that the issue doesn't show on all similar models, but shows
on some, either 32bit or 64bit CPU. Even there, it doesn't show all the time,
sometimes the system works just fine.

Created attachment 5480 [details]
dmesg

dmesg (all timings are wrong, thus the forced lpj otherwise the system can't
read the disk)

Created attachment 5481 [details]
lspci -vv

Created attachment 5482 [details]
/proc/interrupts

Created attachment 5483 [details]
dmidecode

If that's on any help. What I find odd is that the SMBios gives 1.6V for the
CPU while powernow-k8 gives 1.550V max.

Disabling powernow-k8 in the kernel doesn't help either?

Andi: Do you have any clue here?

Oh, and could you please revalidate that it occurs with 2.6.13-rc5?

> Disabling powernow-k8 in the kernel doesn't help either?
No, makes no difference. Seems powernow is loaded later in the boot process.

> Oh, and could you please revalidate that it occurs with 2.6.13-rc5?
Makes no difference either.

Just to make 100% sure, I tried the patch
http://www.ussg.iu.edu/hypermail/linux/kernel/0504.0/1625.html but that doesn't
fix the issue.

With that patch, IRQ0 is labeled XT-PIC but the PIT still goes 3 times too fast.
Also the LOC and IRQ0 counter are in sync.

Could it be some erratum in the southbridge (nforce3) that wouldn't be handled
by the BIOS that could explain that behaviour?

To me it doesn'look like an IRQ routing issue, but really like a rate 3x too
fast in the 82C54, any channel, any mode: if the timer goes 3 times too fast,
the following test;

    grep LOC /proc/interrupts && sleep 10 && grep LOC /proc/interrupts
    LOC:     212737
    LOC:     222772

*but* the sleep last for approx 3 secs (using the watch).

Does anybody has access to nforce3 errata (btw, I'm not even sure the 82C54 is
in the nforce3)? I could find a lot of documentation from AMD but nothing from
NVidia.

Ok, I have some interesting findings. I've always been surprised that Windows
got the timer right while any other system or evcen application was getting the
timer 3 times too fast (see comment on LKML here http://lkml.org/lkml/2005/7/27/7)

After digging a bit, I found that the timer management in windows depends on the
HAL used. I also found that the HAL installed by default on my laptopn is "ACPI
uniprocessor".

I found on Microsoft web site a method to force a Hardware Abstraction Layer
(http://support.microsoft.com/?kbid=299340)

I therefore ripped off my Windows isntalled and used the "Stanard PC " HAL
instead. And guess what? The timre runs 3 times to fast in Windows XP too.

So, my guess is that Windows XP using the ACPI HAL does the same as my patch, ie
calibrate the PIT using the ACPI timer (I actually think Windows uses a variable
tick calibrated on the ACPI timer)

So you think my patch (www.xfce.org/~olivier/r3000) or a similar patch could be
included in the standard kernel ?

PS: The patch on http://www.xfce.org/~olivier/r3000/ has been improved over the
fist one I posted on LKML and is functionning well on i386 and x86_64 architectures.

Olivier: The solid feedback (and patches even!) you've been providing has been
great. I'm not sure if you're patch is really the best approach. I'm hoping
there is some nforce3 errata we can find that specifies what needs to be done to
 get the timer interrupt frequency properly set on a warm reboot. That way we
can specifically blacklist the chipset and special boot options won't be necessary.

John, just for correctness, it's not on warm reboot, it's on cold boot. If by
chance the system boots with the timer right, the timer stays right until the
computer is turned off and on again.

As for the errata I doubt there's one, because Windows would have it implemented
then (w/out ACPI enabled, the problem shows even in XP with all latest available
updates)

Just wanted to say that I was having similar problems on an Athlon64X2 machine
with 2.6.12, and the patch fixed those for me.

John, I've updated my patch and I have it for 2.6.14-rc4. I guess there is still
no chance for inclusion in the kernel in that form or another (ie maybe part of
your own timer patches as an option or something)

Created attachment 6420 [details]
Patch for Linux kernel 2.6.12

Created attachment 6421 [details]
Patch for Linux kernel 2.6.13

Created attachment 6422 [details]
Patch for Linux kernel 2.6.14

Attaching patches directly to the bug report as the URL on my sites aren't
stable these days (sorry for the noise).

Once the patched kernel is built and installed, add the boot parameter to
instruct the kernel to "trust" the ACPI PM timer :

On i386, add :

clock=pmtmr

On x86_64, add :

pmtmr

No way I'm adding the three times read hack into x86-64 pmtmr.  And there
is no evidence it is even needed.

What needs to be done instead is to find out why the TSC is miscalibrated.
 
Does it still happen on 2.6.14?

 
> Does it still happen on 2.6.14?

Yes, that's why I've made the patch available for 2.6.14 too.

Olivier, Could you try the patch posted here to see if it helps?

http://marc.theaimsgroup.com/?l=linux-kernel&m=113249769027262&w=2

Yeap, I've seen taht patch on the LKML.

I'll try and report back. But I would be somehow surprised if that help in my
case for the following reasons:

1) In my case, it's the i8259A rate that's broken
2) The R200 case looks different from my problem. My problem shows as early as
the BIOS at boot and show only intermitendly. I don't think the problem with ATI
is intermittent.
3) I still believe the problem here is a hardware bug that is hidden by Windows
implementation of the timer.

Anyway, I'll try it right now.

I tried and it makes no difference here.
I have a kernel log if needed.

Seems there are several different causes to the same symtoms (unfortunately for
me). On my system (and quite a few, but not all, of these R3000 HP laptops) I'm
pretty sure it's a hardware bug.

The only way to get around it is to "fix" the timer rate by comparing it with
another viable time source, which is just what my patch does.

Olivier: That's unfortunate, I appreciate your time in trying the patch though.
If you could, dmesg output would still be helpful. Thanks again!

Created attachment 6639 [details]
Kernel log with R200 patch applied

The patch has been applied on both archs i386 and x86_64 on a 2.6.15-rc2
kernel.

I'm currently running in x86_64 mode.

Comment on attachment 6639 [details]
Kernel log with R200 patch applied

Better (more complete log) available

Created attachment 6640 [details]
Kernel log with R200 patch applied (new)

The kernel is 2.6.15-rc2 patched with the suggested patch (applied on the
x86_64 tree).

The previous log was truncated (log buffer too small on recent kernels)

This new one shows the issue at boot.

PM-Timer running at invalid rate: 33% of normal - aborting.
time.c: Using 3.579545 MHz PM timer.
time.c: Detected 731.484 MHz processor.
time.c: Using PIT/TSC based timekeeping.

FYI I have kernel with both patches applied (from comments #21 and #25) and my 
kernel runs twice fast on i686 smp kernel run on i686 up machine. Without these 
patches everything is ok.

I mean clock of course.

Just tried Andi's patch posted on the ML http://lkml.org/lkml/2005/11/26/32

Makes no difference.

Created attachment 6688 [details]
Kernel log with Andi's patch applied

Looking at your log it's probably a different problem - not the APIC routing
issue. It might be related to the fact that your system boots with 800Mhz
and then the CPU is later scaled up.

Does it work correctly with "notsc" or not loading any powernow modules?

Unfortunately not, the notsc has no effect neither does removing the powernow
modules.

The problem is that the interrupts run 3x too fast. The CPU is initialized at
2200MHz by the BIOS (that's sure, it was the fix of the latest F35 BIOS), but it
really looks like the hardware generates 3x too much interrupts, so the detected
(computed) cpu speed is 3x lower that it's actual value.

That has some very nasty effects too as the DMA timings are all broken (got a
bunch of fake HD errors because of that).

Your bootlog says it starts with 800Mhz. With removing powernow I meant
never loading them - did you do that?

The detected CPU speed won't directly impact the interrupt rate because
it's fixed - in your case it's generated by the PIT which runs
with a defined frequency (unless the hardware is totally broken) 

Then there is the local APIC timer which is used for timing event
with APIC on , but that should also run independent
of the CPU frequency because it's clocked off the northbridge clock.
In your case it seems to be miscalibrated though. The bootlog 
says its running with 4Mhz,  but normally on a 800 HT systems it's
supported to run with ~12Mhz (at least it does that on my desktop)

The APIC clock is supposed to be constant, but perhaps it's not
the case. I suspect your problem will go away if you keep 
the system at 800Mhz. Correct?

> Your bootlog says it starts with 800Mhz. With removing powernow I meant
> never loading them - did you do that?

Yes, sure.

> The detected CPU speed won't directly impact the interrupt rate because
> it's fixed - in your case it's generated by the PIT which runs
> with a defined frequency (unless the hardware is totally broken) 

The hardware *is totally broken*. It's what I'm trying to tell from the very
first time.

But i's not just my laptopn, it's quite a few of the same model. Not all though,
some are fine :/

> Then there is the local APIC timer which is used for timing event
> with APIC on , but that should also run independent
of>  the CPU frequency because it's clocked off the northbridge clock.
> In your case it seems to be miscalibrated though. The bootlog 
> says its running with 4Mhz,  but normally on a 800 HT systems it's
> supported to run with ~12Mhz (at least it does that on my desktop)

The CPU always runs at ~2200MHz and the APIC timer runs at ~12,455MHz . But as
the PIT timer that is used to calibrate those values run 3x too fast, the
computed values are 3x too low. Simple.

2200/3 = 733MHz which is the wrong computer speed displayed in the boot log
(actually 731Mhz)

> The APIC clock is supposed to be constant, but perhaps it's not
> the case. I suspect your problem will go away if you keep 
> the system at 800Mhz. Correct?

The problem never, ever goes away. It appears after a short power off/power on
cycle. Once it appears, I have to leave the laptop off for about an hour to get
a chance to have the system run at a correct speed.

That's why I've made my patch that computes the correct rate to pass to the PIT
timer to get the real interrupt rate.

The algorithm I use is simple:

- Program the PIT at a good value
- Wait for a short period of time
- Computer the ratio to program the PIT to get a correct interrupt rate
(Sometimes it's 1, sometimes it's 3, randomly)

Windows wit hthe ACPI HAL does not show the problem because I beleive it does
something somehow similar, it uses the PM timer to calibrate its variable tick rate.

Created attachment 6692 [details]
Patch for kernel 2.6.12

New version of the patch for kernel 2.6.12

Created attachment 6693 [details]
patch for kernel 2.6.13

New version of the patch for kernel 2.6.13

Created attachment 6694 [details]
Patch for kernel 2.6.14

New version of the patch for kernel 2.6.14

Created attachment 6695 [details]
Patch for kernel 2.6.15-rc2

New version of the patch for kernel 2.6.15-rc2

Sorry for the mail traffic :(

I've attached new versions of my patch, that fixes the issue decribed at #33 on
i386, and also, I believe, a less intrusive change to the existing code.

The ration is used only if "pmtmr" is explicitely given on the cmd line (on
i386, add "clock=pmtmr", on x86_64, simply add "pmtmr") and also if the PM Timer
rate is out of the 5% bounds.

The patches are also available from http://www.xfce.org/~olivier/r3000/

Ok I see what your patch is doing.

One might consider to just refuse to support such broken hardware
I wonder what the hardware designers were thinking? 

Anyways -  Did you really need the "read pmtimer three times" hack?
I would prefer not to add that unless absolutely needed.

And why are you adding the verify pmtmr function to 64bit when
you're saying that the PIT doesn't run at the corect frequency?
That doesn't make much sense because it cannot even work on your
system.

Also please look up the concept of include files instead of spreading
externs everywhere.

And can someone add dmidecode output for that broken machine?

Sure, it's already there:
http://bugzilla.kernel.org/attachment.cgi?id=5483&action=view

> Ok I see what your patch is doing.

Thanks!

> One might consider to just refuse to support such broken hardware

Absolutely, there is nothing I can argue here. This hardware is clearly designed
and tested with Windows. And it works with Windows. So if more laptop builders
just test their hardware with that system, we might see more of these timer
problems in the future. Just a rough (pessimistic) guess though.

> I wonder what the hardware designers were thinking? 

Unfortunately I can't answer this question. And I wonder what I was thinking
when I bought it. But that's definitely another story... :)

> Anyways -  Did you really need the "read pmtimer three times" hack?
> I would prefer not to add that unless absolutely needed.

Possibly not. It was like that in the i386 version so I just started from that.
I can surely test without...

> And why are you adding the verify pmtmr function to 64bit when
> you're saying that the PIT doesn't run at the corect frequency?
> That doesn't make much sense because it cannot even work on your
> system.

The thing is that the problem is intermitent. Sometimes the PIT runs at the
correct frequency. The verify_pmtmr_rate() function is really the heart of the
patch. It compute the ratio to apply to the PIT timer to get the correct rate.
If the PMTMR is within the 5% limits, the ratio is simply not applied (this is
totally similar to what's done for i386).

> Also please look up the concept of include files instead of spreading
> externs everywhere.

Sure ;) The point was to keep the patch as little intrusive as possible. I was
afraid of adding or changing yet another header in the kernel.

Created attachment 6708 [details]
Patch for kernel 2.6.14

New patch for 2.6.14 made after Andi's comments.

Created attachment 6709 [details]
Patch for kernel 2.6.15-rc2

New patch for 2.6.15-rc2 made after Andi's comments.

Created attachment 6933 [details]
Patch for kernel 2.6.15

I decided giving up and just switching to the lapic timer on these boards.
I implemented this some time ago anyways for my noidletick patchkit,
but never pushed it because one of my test machines didn't like it
(they stopped the apic timer in C3). Just need to extract that code.

But the problem how to detect the problem and turn it on. For ATI it's easy.
For the broken nforce3 boards it's difficult. Perhaps your way of 
testing it against the pmtimer is reasonable.

P.S.: Your last patch is some html file, but it doesn't matter.

Created attachment 6946 [details]
Patch for kernel 2.6.15

> P.S.: Your last patch is some html file, but it doesn't matter.
Woops, sorry, that should fix it.

After various tries I gave up on the PIT routing on ATI.
New approach simply uses the APIC timer to drive the main clock. I had
implemented this long ago for dynticks, but didn't push it 
back then because there was one buggy HP nforce3 laptop
where the BIOS broke the APIC timer in C3. 

Another problem right now is that it doesn't work on Intel systems for unknown
reasons, but on those PIT typically works.

Anyways, people who see problems here please test
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/x86_64-2.6.16-rc1-060118-2.bz2

> Anyways, people who see problems here please test
> ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/x86_64-2.6.16-rc1-060118-2.bz2

Andi, I tried your patch and that doesn't fix the issue with the timer running
3x too fast.

Wait, you're the person with the Nforce3 and the totally miswired PIT timer in
hardware right?  For that one it is not intended to work - the APIC timer is
still calibrated from the PIT even with that patch. To solve that one it would
need to be calibrated from the pmtimer. To be honest your bug is low 
priority for me because it seems to be just a single monkeyed up board type, not
a  systematic problem happening on a lot of machines.

I was mostly interested in feedback from ATI and Nforce4 users with too
fast timers right now.  

Unfortunately this bug is a wild mix of various different but unrelated
problems that just happen to have similar symptons. Maybe it would be 
best to fork it.

Sorry, but the bug is exactly the problem I have with a similar HP laptop with
the same hardware (please reread the original bug description). Maybe you got
confused with anither bug report (there are wuite a few for ATI too)

Hmm, yes indeed. Must have hit the wrong bug (strangely it seems to be the only
one of the t imer bugs assigned to me) Ok ignore the patch. Sorry.

But to fix your problem would just need to calibrate cpu_khz with the PMtimer
instead of the PIT I think - then the APIC timer would be calibrated to the
correct frequency and it should just wokr.

If you could convert your patch into just doing that on top of the patch i
posted earlier I would apply the patch. Thanks.

> If you could convert your patch into just doing that on top of the patch i
> posted earlier I would apply the patch. Thanks.

Sounds interesting :) I'll try to prepare a patch then.

Andi: Well, its more then calibrating cpu_khz, as if the timer interrupts are
coming in too fast, jiffies will be increasing too quickly. Thus the timer
frequency has to be estimated and re-programmed (as dont in Oliver's patch) to
provide something close to ACT_HZ freq. 

Olivier: I appreciate your persistence in maintining your current patch. While I
still don't think it is acceptable, maybe the following ideas might allow it to
go in:

1) Could we avoid detecting this via the pmtmr calibration, and instead use a
DMI blacklist so we make sure we only trigger this on known problematic systems.
This also avoids the need for redefining existing boot time options (it would
just work :)

2) The latch adjustment should probably be cleaned up a bit. I'm not confident
you've got all the LATCH users fixed (apm suspend?) and the redudency points to
a need to clean up the PIT programming code.

3) Could you provide some clock drift numbers to show how good the re-estimated
and programmed frequency is to the expected HZ frequency?

thanks
-john

The patch I posted avoids this problem completely by using 
the local APIC timer. It won't work on all platforms, but should 
on near all of the affected AMD systems.

Andi: I'll take that back upon second reading of what your patch does.
Re-calibrating the cpu_khz would probably be sufficent.

Although I would like to see the conditional for this be a machine specific
blacklist.

Why? If APIC timer works it is great because it will be much friendlier
to dyntick. And it was always quite dumb to run two different timers on the BP.

And I'm frankly sick and tired of dealing with interrupt 0 routing issues all
the time.  XP apparently uses the APIC timer, so this part is very undertested
in BIOS and hardware and sometimes hopelessly broken (like in the laptop
in this bug) 

It won't work on newer Intel CPUs though and at least one broken AMD bios.
So we won't get rid of this can of worms completely, but at least it will
be better. I also need to still figure out why it doesn't work even
on older Intel CPUs.

Olivier: I realize you might not be able to freely change arch or boot just any
kernel, but if possible I'd be very interested to hear what happens on your
system w/ 2.6.16-rc1-mm1 for i386.

Andi: Not sure if our discussion is interleaving. Regarding comment #64, I'm
just suggesting the conditional for recomputing cpu_khz based on the pmtimer
instead of the PIT to be conditional on this system being broken. That way we
have some documenation on which hardware has which problems, so future changes
dont' bring out this issue agian.

For i386 we may need something like what I suggested in comment #61, or some
conditional port of your lapic usage as well.

Ah ok - i thought you were arguing against using it for the main timer.
I see your point regarding the calibration. I considered that too.

If the code decides to use pmtimer it should use pmtimer based calibration.

This laptop won't though because it is single core - in this case it will
indeed need a DMI entry to force pmtimer.

Hi John,

In reply to your comment #61:

> 1) Could we avoid detecting this via the pmtmr calibration, and instead use a
> DMI blacklist so we make sure we only trigger this on known problematic systems.
> This also avoids the need for redefining existing boot time options (it would
> just work :)

Nope, I doubt it would work (unless I misunderstood your comment) because the
problem is intermittent (as described in the bug description). It means that
sometimes the system boots right, sometimes it runs 3x too fast. So blacklisting
won't help here. Plus, most of those laptops just work fine, blacklisting them
will lead to a bunch of problems.

That's why I do believe calibration is the only way to work arround that
problem. I perfectly understand that such a fix may not be suitable in the
general case, but the proposed solution is technically the safest way to work
arround the problem. It may or may not fit, that's another problem. 

It would be just great if we could have something working as it's a big problem
using Linux on that laptop (which makes the laptop mostly useless for me without
the patch.)

Cheers
Olivier.

The problem I have with calibration is that if we calibrate e.g. 
the PIT against the pmtimer how do we decide which is one is wrong and which
one is right? Apparently there are both systems with wrong PIT and wrong
pmtimer (at least on i386, haven't heard of such a 64bit beasts, but I'm
sure some motherboard designer will screw that up sooner or later) 

So it needs some table based on system and command line options.

I don't know what you mean with blacklisting will break many of these
laptops. With DMI it's possible to only exclude very specific models.

So the only patch still needed is some way to calibrate the APIC timer
against pmtimer and then the rest can be done with DMI entries/command
line options.  I thought you wanted send me a patch for that? 
If not I'll do it myself.

>1) Could we avoid detecting this via the pmtmr calibration, and instead use a
>> DMI blacklist so we make sure we only trigger this on known problematic systems.
>> This also avoids the need for redefining existing boot time options (it would
>> just work :)
> 
> Nope, I doubt it would work (unless I misunderstood your comment) because the
> problem is intermittent (as described in the bug description). It means that
> sometimes the system boots right, sometimes it runs 3x too fast. So 
> blacklisting won't help here. Plus, most of those laptops just work fine,
> blacklisting them will lead to a bunch of problems.

I still believe the re-calibration is needed, however what I'm suggesting is
that that re-calibration only occurs on systems where we know this issue occurs.

This avoids the issue Andi pointed out where we wont' falsely trigger and
re-calibrate the PIT on a system w/ a bad ACPI PM timer, and additionally avoids
the need for boot time options.

Created attachment 7186 [details]
Calibrate APIC timer using PM timer

I came up with this patch now. It calibrates the APIC timer using the PM
timer. it is relative to the firstfloor x86-64 tree and requires the
apic-main-timer patch in there.

So far the pmtimer calibration defaults to off, but can be enabled with
"apicpmtimer". Does it work with this patch and apicpmtimer?

Created attachment 7190 [details]
Log of 2.6.16-rc1-mm4 with apic-main-timer.patch and apic-pm-timer.patch

Hi Andy,

I tried the patch and it doesn't fix the issue with the timer. The system clock
 still runs 3x times too fast even with "apicpmtimer" and moreover I now get a
bunch of soft lockups. Actulally the system hangs until I generate an event
using either the keyboard or the mouse.

Also, it seems that the CPU and bogomips calibration still use the PIT timer
which is wrong, so all these calibrations are also wrong (according to the
log).

PS: I really appreciate the time you and John spend on this.
Thanks
Olivier.

Andy, I tried with the latest 2.6.16-rc2-mm1 with apicpmtimer and apicmaintimer
options set but the closk still runs too fast.

It seems your previous patches got merged (at least partially) so they don't
apply anymore and I'm not sure where I should start to investigate now.

Any hint would be greatly welcomed ;)

Hmm, can you stick a printk into the pmtmr part in calibrate_APIC_clock
and double check it's really executed?

The frequency from your old log looks roughly ok:

Detected 12.481 MHz APIC timer.

My AMD boxes here have something in that ballpark too (e.g. 12.500Mhz 
on this machine, the small difference should not matter)

I assume you still see that frequency with the latest kernel, right?
With that i don't know what could be still wrong.

Anyways, i guess i need to implement a new timer mode anyways
for ATI boards with broken C2, perhaps that will help in your case too.

Hi Andi,

With 2.6.16 and your latest fixes (ie using "apicpmtimer"), it works mostly
well. The clock runs at a correct speed except for some apps that still runs way
too fast (like games for examples). 

Do you think that be fixed too? My own patch that calibrates the PIT doesn't
address this issue either.

Cheers,
Olivier.

I realize that my comment is a little late, but I recently  discovered that
disabling "PCI Spread Spectrum" and "HT Spread Spectrum" fixed the double-speed
clock on my ASUS A8N-VM based system running an Athlon 64 X2 3800+ processor. 
Chipset is NVidia's nForce 410.  Running stock 2.6.17.11 kernel.  No extra patch
required.

Ah i had nearly forgotten about this.

John, this means that apicmaintimer might be still needed and can't be dropped
in your rework.

Andi,

can we close this one ?

    tglx

> can we close this one ?

I am not Andy, but as far as I am concerned, yes, the hardware has finally died
for good and the issue went away once I replaced the motherboard in the laptop.

This bug still affects my wife's notebook every other boot up.  Running FC6 with
latest updates, which means some 2.6.20 kernel.

Any updates on this problem? Is it still there in 2.6.23+?
Thanks.

Is anything happening about this?  Are there any workarounds?  I am still getting the 3x speed problem with kernel 2.6.28 on an AMD64 laptop.

As in 2.6.18, I am not that up to date!

Could you try a more recent upstream kernel? 2.6.23 perhaps? 2.6.18 is not actively maintained anymore. (unless your distro does it)

FWIW, we haven't observed this problem any more with 2.6.23.  I don't remember when we last hit it, unfortunately.

John, did you get chance to try #87? Anyone else can confirm the bug with the latest kernel?

I guess the bug is gone. Closing.

I am afraid it has not.  I am now in kernel 2.6.25 and the problem is still happening.  Every time I boot the computer after it has been off for a while the clock is running at 3 times speed.  I have to do a cold restart and then it runs correctly.

I am now on 2.6.30 and the problem is as bad as ever.

John Talbut: Can you provide any details on your specific hardware? Is it exactly the same as Olivier's? Can you provide dmesg / dmidecode info? Could you also provide output from:
 cat /sys/devices/system/clocksource/clocksource0/current_clocksource

Oliver's:
Hardware Environment: HP Pavilion zv5000z notebook PC - AMD Athlon64 3000+, AMD
K8 Northbridge, nVidia nForce3 PCI bridge, 64 MB nVidia GeForce 4 440 Go
graphics, 768 MB PC2700 SODIMM...

Mine:
HP Compaq nx9105 notebook PC - AMD Athlon(tm) XP Processor 2800+,  AMD K8 Northbridge, nVidia Corporation nForce3 PCI Bridge, nVidia Corporation NV17 [GeForce4 420 Go 32M] graphics, 256MB SDRAM/DIMM

My software is Debian testing.

dmesg and dmidecode info attached.

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
pit

I currently have clock=pit in my boot parameters, I have tried the other settings and they do not seem to make any difference.

Created attachment 23230 [details]
nx9105 dmesg and dmidecode