Andi Kleen at SUSE believes it to be bad SMM code in my motherboard's BIOS -- the code is slow and causing problems.

Through some testing I found out that if I set TIMER_HZ to 100 the problem was less frequent. Using TIMER_HZ=1000 filled the logs with warnings. I have tried various 2.6.12 and 2.6.13 (including -mm) kernels with just about every kernel parameter possible with no success.

Has anyone actually solved their "Your time source seems to be instable or some driver is hogging interrupts" problem and checked it via the "report_lost_ticks" kernel parameter? If so, could you post your hardware list? Better yet, are there any folks with similar hardware to mine that don't have this issue at all?

The DFI board's been great for me. I had the lost ticks problem with both the neo4 and the DFI, and I posted a fix in that worked for me on the last page of that thread. For some reason it stopped booting one day with clock=pmtmr, but if you remove that part it'll work fine._________________"we should make it a law that all geeks have dates" - Linus

Using latest ~amd64 kernel with timers enabled in the kernel has solved the problem for me.

Chad Simmons

which kernel out of curiosity, the gentoo sources? I've been using 2.6.13-rc1, since rc3 gave me some problems with the nvidia drivers._________________"we should make it a law that all geeks have dates" - Linus

For those who think their timer problems have been solved, could you try booting with 'report_lost_ticks' and see if you still get errors such as:

time.c: Lost 1 timer tick(s)! rip acpi_processor_idle+0x137/0x389)

I've gotten some configs where the kernel wouldn't complain much, but after adding that boot parameter I found I still had issues. I guess a single lost tick here and there isn't enough to get the kernel to issue warnings.

For those who think their timer problems have been solved, could you try booting with 'report_lost_ticks' and see if you still get errors such as:

time.c: Lost 1 timer tick(s)! rip acpi_processor_idle+0x137/0x389)

I've gotten some configs where the kernel wouldn't complain much, but after adding that boot parameter I found I still had issues. I guess a single lost tick here and there isn't enough to get the kernel to issue warnings.

I'll have to look at that, but the real problem I had was that my clock was running way too fast, and would cause all sorts of havoc when under a high load. Videos would play too fast, tapping a key would result in it thinking I had been holding it down for awhile, etc. Since I've had such visible side affects from it, and they're gone now, I'm happy._________________"we should make it a law that all geeks have dates" - Linus

Speaking of keyboard anomalies on an nForce4 board with an X2 processor, I have experienced some issues other than those you described, but I still believe that what I have posted will be useful.

On occasion, there are governor problems that result in an 'oops' that only kills the keyboard but not the machine. For a while, I had thought that it was some KVM problem, but it became clear that it wasn't.

Take a look at some of the resources in this bugzilla report, and consider applying the patch listed in one of the mailing list threads to the kernel.

Have you applied the powernow-k8 patch? Since I applied that, I have a completely clean dmesg from boot to shutdown.

Rob.

Yes, I applied the patch, and dmesg has been henceforth clean of these notifications. There have been no more panics as well. The only complaint that I will lodge is that some driver (skb) or (skge) has been dumping a lot of garbage as of late:

Ah right, I also applied the patch for the sk98lin driver, and am now using my Marvell ethernet port, rather than forcedeth... I was having a few problems with the forcedeth driver not locking the machine, but locking the net, with the transmission light constantly being lit.

Not sure if it is linked... new MB Neo4 X2 proc 4200... I have insane clock drift... clock going too fast around 10min per hour.

No message in dmesg about lost ticks though....

I used a config derived from LiveCD as I could not boot otherwise. Only change I did are driver related I think (sata, nv_sata, skge). I disabled CnQ (BIOS and kernel) as it does not work (I am not up for patching my kernel yet).