# System Clock Drift [SOLVED]

## Se7enLC

I have a weird problem with my clock that cropped up suddenly. Not sure what caused it, but it was right after I moved my / partition to a different drive, and right around the time change, but it could be anything.

Anyway, the problem I have is a system clock that drifts significantly. I'm talking 10 minutes out of every hour or so. What's weird, however, is that the Hardware clock is correct. That's right, when I run "hwclock" it returns the time, as perfect as it was when I set it 12 hours ago or so (and I'm not running ntp or anything like that), but "Date" turns up the b0rked time.

Speaking of ntp, please don't just give me a one word answer like "ntp" or a link to another post where somebody installed ntp. I read through every time drift post I could find, and tried installing both ntp and openntp (different occasions) following the exact instructions. ntp did nothing. It ran, but never adjusted my clock OR generated errors. Openntp immediately started telling me that it was adjusting my clock. Every few minutes it would say "adjusting by x.xxxx seconds" or something, where x.xxxx started at around 9 seconds, and by morning it was over 700 each time, and the clock was wrong (looks like it never actually did any adjusting).

I don't have an objection to running ntp (if it worked), but I'd just as soon use my hardware clock, since it's always worked in the past, and I don't see why I can't continue using it, except that it all of a sudden the system time drifts away from it.

Thanks for any help you can give, this problem has been irritating me for a week nowLast edited by Se7enLC on Tue Aug 16, 2005 9:31 pm; edited 1 time in total

----------

## bendagr8

try deleting /etc/adjtime

----------

## dsd

is it an nforce2 based motherboard by any chance?

----------

## Se7enLC

Nope, it's a via board, Gigabyte 7vAXP, I think.

I've tried deleting /etc/adjtime before, but I'll try it right now, reset my system time, and see if that does anything new:

```
[root@djali jeff]$ rm /etc/adjtime 

[root@djali jeff]$ /etc/init.d/rdate 

Setting Clock (rdate): Fri Nov 5 09:24:24 EST 2004

[root@djali jeff]$ date

Fri Nov  5 09:24:28 EST 2004

[root@djali jeff]$ hwclock

Fri Nov  5 09:24:33 2004  -0.353111 seconds

```

ok, right now system time and hardware time are in sync, I'll check back in an hour or two to see what the skew is.

Other suggestions welcome while we wait to see what this one does  :Smile: 

----------

## bendagr8

This may help isolate the problem if this didn't fix it. I never tried it, so no guarantees.

```

rm /etc/adjtime

touch /etc/adjtime

chmod a-w /etc/adjtime

```

This way you can see how much your sysclock skews normally without anything trying to alter it. 

If it looks like this is making progress (ie. vastly different skew amounts than before), try to find which process was trying to alter that file, and then look into that process to see what it's problem is. You should then be able to use ntp to keep it updated.

EDIT: you'll have to give back write permissions to adjtime, once you take care of the error

If it isn't make progress, then I have no clue.

Another solution of course is use create a cron job to periodically rdate. I don't use rdate, so I couldn't tell you the exact command.

*Sorry if this was all common sense, but I had a sysclock problem recently, and it was the biggest pain. I couldn't find much help here either, so I figured I'd just say something (better than nothing).

----------

## Se7enLC

[root@djali jeff]$ date ; hwclock

Fri Nov  5 11:15:53 EST 2004

Fri Nov  5 11:18:43 2004  -0.020354 seconds

My skew is already a few minutes. Rather than let it keep going, I just did what you suggested about preventing writes to /etc/adjtime. I'm going to let it go like that for awhile and see if it skews better or worse.

----------

## bendagr8

I just thought... if the skew is the same after taking away write permission, it probably means something should be writing to adjtime that isn't.

So double check write permissions are there, and read up on what is suppoed to be writing to that, and then check that out.

----------

## Se7enLC

what does /etc/adjtime do exactly? I know the basic idea, that it's an offset to correct for drift, but which clock is it using?

*hypothetically* I shouldn't need this file at all. My hardware clock keeps perfect time, it doesn't drift at all. Unless there's some limitation that makes me have to use the system clock.....

----------

## bendagr8

So this is just my educated guess on the matter, and it could be entirely incorrect.

The OS has some clock which may or may not be accurate... it's trying to keep track of the time based on something. I assume its somewhat hardware in nature (read below for the example), but it differs from the physical component which is the hardware clock.

In order to make it more accurate, your system will try to speed it up or slow it down. It puts some value in the adjtime file which is kind of like a multiplier. 

[example]

So a dumbed down, possibly very wrong example may be:

normally, the system says 1 second is 1000 CPU cycles, but the clock is behind, so lets say 1 second is 750 CPU cycles for now to get it back to speed.

or we're running fast so lets say 1100 CPU cycles is 1 second.

[/example]

I mean perhaps it has nothing to do with CPU cycles,but it must have some type of relation to the hardware.

So I guess if you don't have ntp, your system is going to look at the hwclock, a physical entity, to make adjtime modifications. If you have ntp, it will use that number instead of hwclock.

So to sum up, adjtime is definitely a multiplier for the system clock. The rest of what I say, may vary from totally correct to totally false. Reader discretion is advised.

----------

## Se7enLC

I tried all the suggestions above, I was still off by about 20 minutes by 7pm.

Not sure about /etc/adjtime - I can't seem to find any programs that alter it, except "hwclock"....but it seems that hwclock is for adjusting the hardware clock, not the system clock

Any other ideas on why my clock is fscked?

----------

## Rainmaker

have you tried a bios update?

----------

## jphelps

I had a similar problem on fedora but the drift was much worse.  One of the symptoms was the sw clock would keep perfect time when the CPU was at 100% use.  This has not been resolved under fedora and does not occur to me (on the same HW) under Gentoo.

Your HW and BIOS are fine.

----------

## Se7enLC

 *Quote:*   

> have you tried a bios update?

 

Seeing as I've had this system for a few years and never had a problem with the time until last week, I don't think a bios update is going to fix things. Plus, the hardware clock is fine.

 *Quote:*   

> the sw clock would keep perfect time when the CPU was at 100% use.

 

Do you mean that it would only keep time when it was at 100% use? or it would only lose time at 100% use? That might be one of the causes, my system does jump up to 100% every so often (I have dual monitors on a geForce2 MX.....trying to run OpenGL. Sometimes it's a little sluggish).

So I found some more information on the situation, and it seems system time drifting is pretty common, since it's based on kernel timer interrupts, which aren't all that accurate. So I decided to try ntp again. I got it installed and working, however the time STILL DRIFTS. The offset column started off around 200,000, but now (8 hours later or so) it's over a million. My clock says 10:18, but it's really 10:50. HEELLLLLP!!!

```

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

 time.uswo.net   198.82.1.201     3 u  578 1024  375  218.641  1886965 77438.1

 thor.capfed1.si 128.9.176.30     2 u  518 1024  173  370.635  1889390 32264.0

 200.10.140.2.ad 204.123.2.72     2 u  506 1024  377  345.422  1890211 32556.0

 200.49.40.15.ad 192.43.244.18    2 u  517 1024  275  482.954  1889779 76382.2

```

And here's what I find in my system log. Not the curious lack of "your time is being adjusted" or anything like that:

```

Nov  6 10:29:53 [ntpd] ntpd 4.2.0@1.1161-r Fri Nov  5 20:17:55 EST 2004 (1)

Nov  6 10:29:53 [ntpd] precision = 9.000 usec

Nov  6 10:29:53 [ntpd] no IPv6 interfaces found

Nov  6 10:29:53 [ntpd] kernel time sync status 0040

```

I was able to bring ntp into debug mode with the -d flag. I'm not sure what I'm looking for, but I figure I should post this in case it helps anyone else, or if somebody can find what is wrong:

```

[root@djali jeff]$ /etc/init.d/ntpd start

 * Starting ntpd...

ntpd 4.2.0@1.1161-r Fri Nov  5 20:17:55 EST 2004 (1)

addto_syslog: ntpd 4.2.0@1.1161-r Fri Nov  5 20:17:55 EST 2004 (1)

addto_syslog: precision = 9.000 usec

create_sockets(123)

addto_syslog: no IPv6 interfaces found

bind() fd 4, family 2, port 123, addr 0.0.0.0, flags=8

bind() fd 5, family 2, port 123, addr 127.0.0.1, flags=0

bind() fd 6, family 2, port 123, addr 192.168.2.150, flags=8

bind() fd 7, family 2, port 123, addr 192.168.1.1, flags=8

bind() fd 8, family 2, port 123, addr 172.16.131.1, flags=8

bind() fd 9, family 2, port 123, addr 172.16.132.1, flags=8

init_io: maxactivefd 9

local_clock: at 0 state 0

key_expire: at 0

peer_clear: at 0 assoc ID 3724 refid INIT

newpeer: 192.168.2.150->64.113.215.94 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000

key_expire: at 0

peer_clear: at 0 assoc ID 3725 refid INIT

newpeer: 192.168.2.150->216.244.192.3 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000

key_expire: at 0

peer_clear: at 0 assoc ID 3726 refid INIT

newpeer: 192.168.2.150->200.10.140.2 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0  key 00000000

key_expire: at 0

peer_clear: at 0 assoc ID 3727 refid INIT

newpeer: 192.168.2.150->200.49.40.15 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0  key 00000000

addto_syslog: frequency initialized 0.000 PPM from /var/lib/ntp/ntp.drift

local_clock: at 0 state 1

report_event: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspe c, 1 event, event_unspec' (0xc010)

transmit: at 1 192.168.2.150->64.113.215.94 mode 3

auth_agekeys: at 1 keys 1 expired 0

timer: refresh ts 0

transmit: at 2 192.168.2.150->216.244.192.3 mode 3

transmit: at 3 192.168.2.150->200.10.140.2 mode 3

receive: at 3 192.168.2.150<-200.10.140.2 mode 4 code 1

peer 200.10.140.2 event 'event_reach' (0x84) status 'unreach, conf, 1 event, eve nt_reach' (0xa014)

clock_filter: n 1 off 1971.418746 del 0.587746 dsp 7.937510 jit 0.000008, age 3

transmit: at 4 192.168.2.150->200.49.40.15 mode 3

receive: at 4 192.168.2.150<-200.49.40.15 mode 4 code 1

peer 200.49.40.15 event 'event_reach' (0x84) status 'unreach, conf, 1 event, eve nt_reach' (0xa014)

clock_filter: n 1 off 1971.483122 del 0.658973 dsp 7.937511 jit 0.000008, age 4

auth_agekeys: at 60 keys 1 expired 0

transmit: at 67 192.168.2.150->200.10.140.2 mode 3

transmit: at 67 192.168.2.150->64.113.215.94 mode 3

transmit: at 67 192.168.2.150->216.244.192.3 mode 3

receive: at 67 192.168.2.150<-64.113.215.94 mode 4 code 1

peer 64.113.215.94 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0xa014)

clock_filter: n 1 off 1973.149784 del 0.496776 dsp 7.937509 jit 0.000008, age 67

receive: at 67 192.168.2.150<-216.244.192.3 mode 4 code 1

peer 216.244.192.3 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0xa014)

clock_filter: n 1 off 1973.145063 del 0.575130 dsp 7.937512 jit 0.000008, age 67

receive: at 67 192.168.2.150<-200.10.140.2 mode 4 code 1

clock_filter: popcorn 1.735646 0.000008

transmit: at 69 192.168.2.150->200.49.40.15 mode 3

auth_agekeys: at 120 keys 1 expired 0

transmit: at 130 192.168.2.150->216.244.192.3 mode 3

receive: at 130 192.168.2.150<-216.244.192.3 mode 4 code 1

clock_filter: n 2 off 1973.145063 del 0.575130 dsp 3.937991 jit 1.756716, age 130

transmit: at 132 192.168.2.150->200.10.140.2 mode 3

transmit: at 133 192.168.2.150->64.113.215.94 mode 3

transmit: at 133 192.168.2.150->200.49.40.15 mode 3

receive: at 133 192.168.2.150<-64.113.215.94 mode 4 code 1

clock_filter: n 2 off 1974.845593 del 0.459763 dsp 3.937761 jit 1.695810, age 66

receive: at 133 192.168.2.150<-200.49.40.15 mode 4 code 1

key_expire: at 133

clock_filter: popcorn 3.380555 0.000008

auth_agekeys: at 180 keys 1 expired 0

transmit: at 194 192.168.2.150->216.244.192.3 mode 3

receive: at 194 192.168.2.150<-216.244.192.3 mode 4 code 1

key_expire: at 194

clock_filter: n 3 off 1973.145063 del 0.575130 dsp 1.938714 jit 2.993396, age 194

transmit: at 198 192.168.2.150->200.10.140.2 mode 3

receive: at 198 192.168.2.150<-200.10.140.2 mode 4 code 1

key_expire: at 198

clock_filter: n 3 off 1976.927583 del 0.506616 dsp 1.938374 jit 4.721454, age 131

transmit: at 199 192.168.2.150->64.113.215.94 mode 3

receive: at 199 192.168.2.150<-64.113.215.94 mode 4 code 1

key_expire: at 199

clock_filter: n 3 off 1974.845593 del 0.459763 dsp 1.938507 jit 1.978857, age 132

```

ideas? This is driving me nuts...

----------

## Se7enLC

We can safely add upgrading to kernel v 2.6.9, recompiling, rebooting and using an older version of ntp (4.1.2) to the list of things that don't solve the problem. Right now my PC says it's 1:24 am, and it's def 1:50am. argh!

----------

## dentharg

And btw. ntp is time SERVER.

If you want only to correct your timer, use ntpdate.

----------

## markkuk

No, ntpd is both a client and a server for the NTP protocol. "ntpdate" will set the clock once but won't do anything to prevent the clock from drifting afterwards.

----------

## dentharg

A cron job with ntpdate?

----------

## markkuk

 *dentharg wrote:*   

> A cron job with ntpdate?

 No, that's a bad idea!

It doesn't fix the actual problem with Se7enLC's clock.

----------

## dentharg

Hmm.. this explanation got me thinking. But nonetheless ntpd uses resources that ntpdate does not. Running just one more daemon on a desktop machine is not necessarily a good thing.

And I will check my clock drift. Wonder what will turn out...

----------

## markkuk

ntpd uses about 3MB of memory so if you're really starved for RAM you might not want it, but the CPU time usage is essentially zero.

----------

## Se7enLC

Yeah, I know I can set a cron job to fix the time. Until a week or so ago, the only time syncing I had was rdate running once a week - my system clock was accurate enough to keep time on its own.

I really don't want to have to use ntp - I'd like to find out why my kernel can't keep time all of a sudden. Like I said in an earlier post, the hardware clock is accurate

----------

## GeoffOs

I don't think NTP will solve the issue, unless you set the checking to every 20 minutes or so. 

I have not fully investigated this issue, i believe I have motherboard issue, but my clock looses time quite quickly and NTP does not solve the issue as it falls through the 1000 second time difference.

 *Quote:*   

> 
> 
>  7 Nov 15:38:31 ntpd[31748]: time correction of -3830 seconds exceeds sanity limit (1000); set clock manually to the correct $
> 
> 

 

Which i get almost every day, so ntp becomes pointless.

There does appear to be the panic var, but this does not appear to be recognised

http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=ntp.conf

[/url]

----------

## Se7enLC

Yeah, it's not a matter of how often to set the clock, or sync it.....it's a matter of the fact that ntp NEVER sets it. I sync to a time server manually using ntpdate, then I start up ntpd. ntpd doesn't correct my time *ever*. Once it's started, it never makes another peep in the system logs, regardless of what time it is. ntpq and ntptrace both show that it is connected and reporting seemingly accurate offsets though (continuously growing into the millions). Right now my clock says that it's 9:37am. Ironically enough, this is exactly an hour behind the real time. I suppose that it's possible for it to be a timezone glitch, but it's been pretty random.

Does anyone know what this line means? google turned up nothing...

```
Nov  6 18:54:31 [ntpd] kernel time sync status 0040
```

----------

## Se7enLC

YES!!!

I fixed it. I figured it out when my computer slowed to a crawl when writing large files to disk and reading from cds/dvds. I had seen other posts mentioning udma causing the problem before, but assumed that since it was *previously* working, that couldn't be it. So here's what the problem was:

I have 4 IDE channels on my mainboard. The main 2 are via, the extra 2 are promise RAID channels. I previously had my main drives on the promise controller, which had drivers in the kernel. UDMA was enabled on the drives on those controllers. When I installed a new harddrive, I moved the main partitions to the drive on the via controller, and as a result, UDMA was *not* enabled. I added via support to the kernel and rebooted, and it's had the correct time for over an hour, without even needing ntpd!

Thanks for all the suggestions, guys. Hope this thread can help some other people who have similar problems.

----------

## VanWEric

I have a similar problem, but I'm pretty sure it isn't caused by the UDMA, mainly because I haven't touched anything like that.

I have a dell inspiron d600 that dual boots windows and gentoo.  Windows holds the time perfectly.  Gentoo used to hold time perfectly.  Gentoo now slows by about 10 minutes per hour, maybe more.  This might have started after I got my mother board replaced, but I do remember being late to class because of it once before the replacement.  My mother board was being replaced for physical damage (it fought gravity 6 times this summer and only won once).

On a perhaps unrelated note, recently my bootsplash stopped having text and a timer bar:  It has the pretty gentoo logo, but no longer says "Press f2 for details" or whatever.  Don't know if that means anything, and I don't care if it doesn't get fixed, I'm just trying to be thorough.

I just checked my hardware clock, and it was off by 40 minutes.  Again, windows had the correct time - does windows ignore my hardware clock?

Thanks in advance.

Eric

----------

## Se7enLC

are you sure you checked the hardware clock? Try running both hwclock and date separately to see what times they give you

Just to make sure it's not the UDMA issue, run 

```
hdparm /dev/hdX
```

, where X is your drive. Check all of them, since any one of them could be the one causing it, not just the / drive. I didn't touch udma, per se, either.....but because my kernel didn't load the IDE driver, it was forced to use non-udma transfers.

I'm pretty sure windows *only* uses the hardware clock. (I've seen people complain about it since linux/unix likes to use UTC for hardware clock and local time for system clock....and windows likes to get confused whenever it sees UTC). Chances are, if your time is wrong, it's the system time, not the hardware time, since linux doesn't use the hardware clock for anything at all.

----------

## ions

I am having a problem with time drift as well as a problem with DMA.  

The DMA problem can be seen here: https://forums.gentoo.org/viewtopic.php?t=252608

Last night before bed the time was fine - matched to within a minute of what the TV said anyway.  I ran a -uvD --usenew world, any emerge is a painful process w/o DMA, and in the morning, roughly 7 hours later , my time was around 15 minutes off.  

I'd love to get this fixed.  Not only is the slow performance of the missing DMA slowing me down but the clock innacuracy is making me late.

----------

## amightywind

I have the same problem with system clock drift with my ABIT AN7 NForce2 Mobo.  I blow away /etc/adjtime from time to time, and adjust the time using date --set="+..." .  That is hardly a solution. I don't know the relationship  between hwclock and date.  My timezone info seems to be set up ok, and my bios date is also set locally.  One thing I haven't tried is keeping the power supply on even though the board is off. I wonder if it has something to do with the transition to battery power during powerdown.

----------

## newjosch

the adjtime file has no impact on the drift of the system-clock  ( or kernel-clock ).

hwclock uses the contents of this file if you do 'hwclock --adjust.

'man hwclock' gives a good explanation.

The drift of the system clock is controlled by the kernel.

but the kernel does not know how fast the clock should run.

so he need ssome parameters.

these can be contolled by programs like ntpd or adjtimex.

if you dont want to run ntpd try adjtimex

it als has an excellent man page 'man adjtimex'.

with the help of adjtimex you even could adjust the drift rate of the kernel-clock with no ntp-connection. ( only with reference to a precise watch )

does this help ?

regards 

joerg

----------

## amightywind

Joerg,

Thanks for the reply.  My problems with system time stop when I keep my power supply

on even after powering the motherboard off.  The drift must have something to due with

the transition of my motherboard clock from power supply to CMOS battery.

I don't know if this is particular to my ABIT AN7 motherboard or if there are additional

BIOS settings that should be applied.  Now for my usb camera....

Andy

----------

## newjosch

i am not sure if you really are aware that there are two independent time-keeping mechanisms.

Hardware clock is the clock on your motherboard. It should run even with no AC power connected to your machine.

The term System-Clock is used for the clock that is running as part of the kernel.

It must be set during boot because it doesnt know what time it is.

This is done by the script /etc/init.d/clock

Both clocks are running independently as long as you are not running a ntp demon.

If the kernel-clock (system-clock) is drifting it is not caused by your motherboard.

Good sources of information are : 'man hwclock' and 'man adjtimex'

greetings

joerg

----------

## YEL

well i have exactly the same issue and since iam running differnt boxes i reconize one thing all my intel based boxed suffer from the problem except those running kernle version under 2.6 and all the other boxes running 2.6 or higher are having a wrong time other machins with differnt cpus (amd) are not having the problem at all even with 2.6 and higher i would love to know which cpus you all have juts to confirm my suggestion or to know that the problem comes from somewhere else 

well actually i have a workaround 

an hourly running cron jon

ntpdate -B time.fu-berlin.de

but to be honest i hate workarouding i need a fix and ill be glad for any help

regard

YEL

----------

## drescherjm

I had the same problem on a dual processor amd mp 2200 system and the fix for me was deleting the /etc/adjtime file and setting the clock to local. I remember that my problem started after installing gentoo-dev-sources 2.6.9, my clock would be off as much as +- 3 hours. My /etc/adjtime now contains  0.0 0 0.0 and I do not see any random clock drift at all.

----------

## ikshaar

new MB Neo4 X2 proc 4200... I have similar insane clock drift... clock going too fast around 10min per hour.

kernel gentoo-sources-2.6.12-r6

I can (almost) confirm it's disk related. During copy (~5MB/s) from network to an external firewire drive, my clock speed went up even more up to twice normal.

But I don't understand previous solution with UDMA... first firewire drivers are not in kernel (modules) second firewire external drive dont have UDMA, do they ?

Any progress on that "bug" ?

----------

## ikshaar

Update: this is getting insane  :Confused: 

I am copying data to backup drive as before. CPU usage reach 100% on both core.... clock is getting nuts: 1 minute last 9 seconds !! It's not a clock it's a fan !! I cannot type anymore as repeat key is activated all the times due to extra clock speed.

Apart stopping using my drive (!) any clue where to start ?

----------

## UgolinoII

why the big refusal for people to run ntp?

the whole point of ntp is to avoid running ntpdate - go to the ntp site (http://www.eecis.udel.edu/~mills/ntp/html/ntpdate.html) for full explanation - but suffice to say that running ntpdate via cron job is a very bad thing - ntpd is designed to keep your system clock accurate, using minimal resources.

Please read the ntp guide (http://www.ntp.org/ntpfaq/NTP-a-faq.htm), it says for more than i ever could.

----------

## ikshaar

Just to mention ntp is not the problem, nor the solution here....

----------

## ikshaar

SOLVED !

On SMP system RTC is not reliable, so you need to compile HPET and emulate RTC. Just recompiled gentoo-2.6.12 with

HPET_TIMER

HPET_EMULATE_RTC

RTC

(those are in different places in .config)

And so far clock seems stable. Copying data no longer change my clock into a fan  :Razz: 

----------

## drescherjm

 *Quote:*   

> why the big refusal for people to run ntp? 

 

What if your pc is not continuously connected to the internet? Mine was this way for many months until I got my broadband connection installed.

----------

## UgolinoII

no internet !? isn't that like having no electricity !!!

point taken though  :Smile: 

----------

## drescherjm

 *Quote:*   

> no internet !? isn't that like having no electricity !!!

 

I had just moved into a house (in need of a lot of repairs) and I was spending just about all of my free time fixing the house so there was no way I was going to spend $50 / month for internet that I would use at most 1 hour a week...

----------

## ikshaar

 :Crying or Very sad:   the problem is less severe but it did not go away.... over the week-end it went few hours ahead. And now during an emerge I got some "burst"  of time drift. During them , keyboard repeat goes nuts.

My hardware clock (hwclock) stays on time, so it's not hardware.. pure kernel related.

----------

## ikshaar

OK I posted a bug report : https://bugs.gentoo.org/show_bug.cgi?id=102711

Solution - which came very fast  :Smile:  - is for now to upgrade kernel - vanilla-sources-2.6.13-rc6 solves the problem.

----------

## viduliya

 *dsd wrote:*   

> is it an nforce2 based motherboard by any chance?

 

Maybe this will help someone having the same problem on an nforce2 based motherboard.

The following helped me resolved this clock creep problem: 

http://www.ussg.iu.edu/hypermail/linux/kernel/0410.1/1505.html

 *Quote:*   

> 
> 
> From: Andy Currid
> 
> Date: Wed Oct 13 2004 - 15:33:19 EST
> ...

 

----------

## red-wolf76

 *viduliya wrote:*   

>  *dsd wrote:*   is it an nforce2 based motherboard by any chance? 
> 
> Maybe this will help someone having the same problem on an nforce2 based motherboard.
> 
> snip

 It surely did. Thanks viduliya. That info about the FSB spread was spot-on.

----------

