Distribution: Fefora Core 2
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...
Software Environment: Linux x86_64 2.6.8-1.521 (and all earlier versions
including 2.4, 32-bit and 64-bit kernels)
The Linux kernel is having intermittent problems with detecting and setting up
the system clock correctly. The Linux system clock is scaled 3 times too fast
for about 9 out of every 10 cool boot sessions. Rebooting does not appear to
change the behavior of the Linux system clock. If I powered on the machine and
happened to get a normal Linux system clock, I can reboot repeatedly and the
Linux system clock would still be running fine. However, if I powered off and on
the machine, I would have about a 90% chance of getting the fast Linux clock again.
My system dual-boots Linux and Windows XP. The Windows clock is always running
fine. The hardware clock is also running fine - I can see that while the
GRUB boot loader is counting down (in normal time). But when the Linux
kernel takes over, the system (software) clock would likely be scaled 3 times
Followings are the differences in dmesg logs between Linux sessions with normal
and fast system clocks:
Normal > time.c: Detected 797.960 MHz processor.
Fast > time.c: Detected 265.995 MHz processor.
Normal > Calibrating delay loop... 1581.05 BogoMIPS
Fast > Calibrating delay loop... 517.12 BogoMIPS
Normal > Detected 12.468 MHz APIC timer.
Fast > Detected 4.156 MHz APIC timer.
Steps to reproduce:
On a comparable PC, trying power the machine off and on several times and
observe the speed of the Linux system clock.
I can always reproduce the problem here and send dmesg logs.
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 (all timings are wrong, thus the forced lpj otherwise the system can't
read the disk)
Created attachment 5481 [details]
Created attachment 5482 [details]
Created attachment 5483 [details]
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
*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
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
I found on Microsoft web site a method to force a Hardware Abstraction Layer
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
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 :
On x86_64, add :
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?
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
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
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
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
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?
> 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
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
> 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
Also please look up the concept of include files instead of spreading
And can someone add dmidecode output for that broken machine?
Sure, it's already there:
> Ok I see what your patch is doing.
> 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
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
> Anyways, people who see problems here please test
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
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?
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
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.
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 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
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
PS: I really appreciate the time you and John spend on this.
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.
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.
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 184.108.40.206 kernel. No extra patch
Ah i had nearly forgotten about this.
John, this means that apicmaintimer might be still needed and can't be dropped
in your rework.
can we close this one ?
> 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+?
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:
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...
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.
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