Re: Timedirft between system clock and hwclock

Am Donnerstag, den 10.05.2007, 10:06 -0300 schrieb John DeDourek:
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.)

I checked this already and didn´t find such - but I will continue
searching.


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.)

Since I am one of those junkies the system runs at runlevel 3 anyway.
This is going to be my little server - so there are no webcams and other
fancy stuff - only Disks (raid), lots of unused USBs, one DVD-Drive and
the network of course. I will try disabling the network and see what
happens.

You might try posting:
-- the speed (MHz) and type of your processor
Intel E6600 @ 2.40GHz

-- the type of video board/chip and the driver you're running for that
No extra video board only the built in one - see below

$ lspci

00:00.0 Host bridge: Intel Corporation 82Q963/Q965 Memory Controller Hub
(rev 02)
00:01.0 PCI bridge: Intel Corporation 82Q963/Q965 PCI Express Root Port
(rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965
Integrated Graphics Controller (rev 02)
00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network
Connection (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
#4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
#5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI
#2 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
#1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
#2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
#3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI
#1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HO (ICH8DO) LPC Interface
Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801HB (ICH8) SATA AHCI
Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller
(rev 02)

-- the kernel you're running (uname -r)

I tried any I could still find on the net from
kernel-2.6.18-1.2798.fc6.x86_64 to
kernel-2.6.20-1.2948.fc6.x86_64
and every 64bit kernel shows this behavior.

In the meantime I also tried FC7t4 (F7t4) and the newest kernel from
devel.
kernel-2.6.21-1.3116.fc7.x86_64
kernel-2.6.20-1.3104.fc7.x86_64

The good news ist - both of them work fine
and /sys/devices/system/clocksource/clocksource0/available_clocksource
now have tsc, hpet, acpi_pm and jiffies.
the default chosen one is tsc

So I have the option now to wait until F7 comes out or find the
cause/solution for the FC6 kernels. Since I am going to run
vmware-server on the machine I would prefer to stick with the 2.6.18
kernel from FC6 since the newer kernels don´t harmonize with
vmware-server very well. But maybe this will/is also solved within F7
kernels by that time.

I will still "play" with the FC6-Kernels for the next days, and if
everything fails try to get vmware-server running with F7t4.

Thanks for the hints - I will try them and if anybody else has ideas you
are very very welcome to .....

Henry




--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Relevant Pages