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
