Originally Posted by nukem
I found that by disabling any parts of the mother board that I did not use helped alot. So for example I disabled the nvidia ethernet card(I use the marvel one) and Sil SATA controller(I use the nvida one). What I was finding is that the problem really comes down to a timing issue. It seems the system speeds up the clock under load. Try compiling something and look at your time(make sure you can see seconds). I put ntp on my system and all seems to be fine. O one more thing it was more of a problem on older kernels(like yours) im on the latest(220.127.116.11) and its fine.
Oh, very interesting.
Most of the motherboard features are already disabled, at one point I'd disabled everything except the built-in ethernet. Please could you explain about using the 'marvell' instead of 'nvidia ethernet'? I'm currently using the 'forcedeth' kernel driver for the built-in ethernet. I know the kernel has drivers for a Marvell PHY which is apparently featured on this motherboard but I haven't been able to figure out what it does. I only have one RJ-45 port on the back of this motherboard (it's not the 'premium' model or anything).
I've heard a lot about Athlon 64 X2 suffering from timer issues with SMP enabled, so I was curious about this. My 'dmesg' under 2.6.14 does report some timer-related errors. But under 2.6.17 I didn't but still get the problem with the 'nvidia' driver. I will try 18.104.22.168 without the realtime-preempt patch right now, since it's working for you.
Under 2.6.17 once while running a kernel compile 'make' warned of a clock slew, even though ntp isn't installed on here. I had to restart the build because some files ended up with timestamps 3000 seconds in the future. I doubt the timer error is as severe as that though, so I assume that was something else.
I'll try and monitor the system clock somehow. I can get nanoseconds from 'data %s.%N' but then I need a reliable reference. I think it's best if instead use something like 'ntpdate', put the CPU under load for some time, and then run it again to see how much offset there is.
Thanks for this... it's really helpful to hear from someone with very similar hardware.