Bug 144894
Summary: | 2.6.10-1.737_FC3 breaks hwclock functionality on Dell PowerEdge SC420 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bruce Friedman <bruce_friedman> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | bugzilla, chris, graham.hudspith, knutjbj, morenstein, pfrields, rainer.traut, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-08-30 01:48:51 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Bruce Friedman
2005-01-12 15:55:18 UTC
#145128 might be a duplicat of this bug. /sbin/hwclock --show also give select() to /dev/rtc to wait for clock tick timed out. i have dell 8400 enabled smp,ht and a i925sx chipset. by using /sbin/hwclock --directisa I am able to get time without error. Those ther eroor might be in realtime clock. Installed FC3 on Dimension 4700, P4 with HT supported and enabled. Did not get problem until upgraded from provided distribution kernel to 2.6.10-1.741_FC3; problem occurs in both SMP or uniprocessor kernel version. 2.6.10-1.741_FC on Dimension 4600, P4 without HT support works without this problem. (Will try disabling HT in BIOS and also try testing /sbin/hwclock --show from #145128 later today.) Disabling HT in BIOS makes no difference. $hwclock --show displays timout error identical to runlevel scripts for init 3, 5 and 6 (I assume the other levels are similarly affected). This bug #144894 would therefore appear to be the same bug described by #145128. If you (sng., pl.) need additional info please ask! OK, on a whim and desparate, I read from man hwclock 8: " --directisa is meaningful only on an ISA machine or an Alpha (which implements enough of ISA to be, roughly speaking, an ISA machine for hwclockâs purposes). For other machines, it has no effect. This option tells hwclock to use explicit I/O instructions to access the Hardware Clock. Without this option, hwclock will try to use the /dev/rtc device (which it assumes to be driven by the rtc device driver). If it is unable to open the device (for read), it will use the explicit I/O instructions anyway." So I replaced $CLOCKFLAGS on line ~270 in /etc/rc.d/rc.sysinit from: CLOCKFLAGS="$CLOCKFLAGS --hctosys" to: CLOCKFLAGS="$CLOCKFLAGS --directisa --hctosys". I made a similar edit in /etc/rc.d/rc6.d/S01reboot. Superficially at least, it works: no errors are reported. Don't see how it may negatively affect functionality of the clock, but I will do some tests and report back if anyone would like. AFAIK I'm still using the standard initscripts from the distro, didn't update them. I imagine there's something in the kernel causing this; I'm hesitant leaving a userland fix: assuming passing an option to a kernel program qualifies as a userland fix :) I have the same issue with my Dell Optiplex GX280 (lspci shows it uses ICH6) kernel 2.6.10-1.766_FC3 #1. This hwclock problem seems to be only in Fedora kernels. hwclock --show gives the time only if I give the --directisa option On this same machine, when I boot into my custom compiled kernel 2.6.10, I have no problems with running /sbin/hwclock --show works fine (without --directisa) This causes a Dell PowerEdge SC 1425 to hang on boot, when rc.sysinit is doing hwclock after updating to kernel 2.6.10 To avoid hacking init scripts you can just put CLOCKFLAGS="--directisa" in /etc/sysconfig/clock This machine will boot fine under 2.6.5 that came on the FC2 boot media. From the above this sounds like a bug in /dev/rtc in later kernels? I also noticed this on debian: http://lists.debian.org/debian-kernel/2005/01/msg00067.html talking about a genrtc device which works. Also occurs on Dell Poweredge SC420 and Dell Poweredge 2800 with the 2.6.11- 1.14-FC3smp kernel This also occurs on a Dell Dimension 8400 with the 2.6.11-1.14_FC3smp kernel. Another mention on the debian kernel list: http://lists.debian.org/debian-kernel/2004/12/msg00381.html Now using Fedora Core 4, this problem persists. Moreover, the inability for the hardware clock to sync upon boot and restart results in incorrect system time, appearing 1 hour ahead. This ocurrs with a timezone set correctly to Europe-Dublin or Eire, and the UTC option for system clock unchecked. Removing /etc/localtime and resetting it (either by an ln -sf or direct cp), the problem persisted until I re-typed --directisa option to the sysinit and reboot init scripts on the appropriate lines. Using FC4 packaged 2.6.11-1.1369_FC4smp (hyperthreading) and uniprocessor kernels. An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you. I'm still seeing this problem on FC4, using a Dell Dimension 9100. Kernel is kernel-smp-2.6.12-1.1398_FC4. Can someone change the version field to 'fc4' ? I am seeing this, too: [root@pele ~]# hwclock --show select() auf /dev/rtc, um auf Zeittick zu warten, Zeit abgelaufen. [root@pele ~]# uname -a Linux pele 2.6.12-1.1398_FC4smp #1 SMP Fri Jul 15 01:30:13 EDT 2005 i686 i686 i386 GNU/Linux Dell Optiplex GX280, HT enabled, SMP Kernel Dell Dimension 5000, HT enabled, SMP Kernel I get the same problem as everyone else. Strange how they are all Dell machines :-) This is with the kernel-smp-2.6.12-1.1398_FC4 build. Tried Bill McGonigle's suggestion (Comment #7) and this works perfectly. Cheers! However, getting a bit sick of this with Fedora. I realise that this problem also occurs with other distros (e.g. Ubuntu and Debian to name two). However, it does not occur when I boot this very same machine with Gentoo. Comparing the kernels, noticed that the Gentoo one had the following option set: CONFIG_HPET_EMULATE_RTC So, following excellent instructions on: http://voidmain.is-a-geek.net/redhat/fedora_3_kernel_build.html I downloaded kernel-2.6.12-1.1398_FC4.src.rpm and changed the following option using "make menuconfig": Processor type and features ---> [*] HPET Timer Support [*] Provide RTC interrupt <--- this one here! E.g. "Provide RTC interrupt" with the Fedora kernel is unset and my new kernel has it set. Continuing on with the kernel build (I chose the "make && make modules_install && make install" method rather then produce an rpm), I copied my .config into /boot/config-2.6.12-1.1398_hwclock_FC4smp. A diff between the stock Fedora kernel config and mine goes thus: *** config-2.6.12-1.1398_FC4smp 2005-07-15 06:46:13.000000000 +0100 --- config-2.6.12-1.1398_hwclock_FC4smp 2005-08-21 00:49:27.000000000 +0100 *************** *** 1,7 **** # # Automatically generated make config: don't edit ! # Linux kernel version: 2.6.12-1.1398_FC4smp ! # Fri Jul 15 01:27:27 2005 # CONFIG_X86=y CONFIG_MMU=y --- 1,7 ---- # # Automatically generated make config: don't edit ! # Linux kernel version: 2.6.12-1.1398_hwclock_FC4smp ! # Sun Aug 21 00:12:30 2005 # CONFIG_X86=y CONFIG_MMU=y *************** *** 114,120 **** CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y ! # CONFIG_HPET_EMULATE_RTC is not set CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_SCHED_SMT=y --- 114,120 ---- CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y ! CONFIG_HPET_EMULATE_RTC=y CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_SCHED_SMT=y Remembered to comment out the CLOCKFLAGS="--directisa" line in /etc/sysconfig/clock and rebooted. Everything now works. No whinges from the boot-up or shutdown sequences, and get the following output from the shell: [root@spiceisland ~]# hwclock --systohc [root@spiceisland ~]# hwclock --show Sun 21 Aug 2005 01:13:13 AM BST -0.015975 seconds Anyone see any problems with this solution? Fixed in CVS, will be in next errata. *** Bug 164693 has been marked as a duplicate of this bug. *** |