Henry Ritzlmayr wrote:
... kernel: Your time source seems to be instable or
some driver is hogging interupts
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This would be my first guess. The timer mechanism stores only one pending
interrupt. Thus, if the clock interrupt occurs twice while some driver has
interrupts locked out, you typically get only one increment of time and the
system time, which is just the sum of the increments falls behind.
This is made worse by the current standard kernels which have upped the
clock rate from 100 interrupts per second to 250 or more. At 100 interrupts
per second, a device driver needs to lock out interrupts for 10 ms. before a
timer tick is lost. At 1000 interrupts per second, any driver that locks
out interrupts for more than 1ms will cause a timer interrupt loss.
Since driver code runs slower on slower CPUs, this problem also occurs more
often on slower CPUs.
I would first check whether there is a kernel boot parameter to set the
clock
timer rate (often called Hz.). If so, modify the kernel boot line to
set the timer
rater to 100 Hz. and see if that helps. If it does, then the above
describes the
likely cause. (Unfortunately, I am not an expert on kernel boot parameters,
so I don't know the answer to this.)
You may next want to try to identify which device driver is causing the
troubles.
If there are device drivers that run devices that you can temporarily
live without,
e.g. a webcam, try running without that device, either by unplugging it
or by
modifying the module loading system to prevent that from happening.
(Unfortunately,
I am not an expert so I can't tell you the best way to do that.) Also
try running
without your network driver loaded (not a lot of fun, so just for a
trial) and see
if the problem corrects itself. Of course if the problem is with the
hard drive
driver or video driver there's not a lot you can do about it. (Although
if you know
how to drive Linux from the command line, like us old Unix junkies, you
could
boot into run level 3, by adding a 3 to the boot command line. That
would run
your screen as a simple command window, eliminating a lot of driver overhead
for running the GUI. Maybe not fun, but you could at least see if the
problem
goes away, which would tend to implicate the video driver as the one hogging
the interrupts.)
You might try posting:
-- the speed (MHz) and type of your processor
-- the type of video board/chip and the driver you're running for that
-- the kernel you're running (uname -r)
-- the modules you have loaded (/sbin/lsmod I think)
and see if anyone has similar problems with those devices, that kernel
(which includes
the device drivers) and that speed of CPU.
