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: kernelAssignee: Dave Jones <davej>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: 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
Description of problem:
After boot of 2.6.10-1.737_FC3 kernel (or SMP version), hwclock
returns the following:

# hwclock --show
select() to /dev/rtc to wait for clock tick timed out

Version-Release number of selected component (if applicable):
2.6.10-1.737_FC3

How reproducible:
Every time.

Steps to Reproduce:
1. Boot on 2.6.10-1.737_FC3 kernel
2. run "hwclock --show" or "hwclock --systohc"
3.
  
Actual results:
select() to /dev/rtc to wait for clock tick timed out

Expected results:
real hardware clock time returned.

Additional info:
Downgrade to 2.6.9 kernel returns to working hwclock functionality.

Comment 1 Knut J BJuland 2005-01-22 18:42:28 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.


Comment 2 Knut J BJuland 2005-01-22 18:46:23 UTC
by using /sbin/hwclock  --directisa
 I am able to get time without error. Those ther eroor might be in
realtime clock.

Comment 3 Patrick Jon Cooney 2005-02-08 13:47:54 UTC
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.)

Comment 4 Patrick Jon Cooney 2005-02-08 18:29:06 UTC
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!

Comment 5 Patrick Jon Cooney 2005-02-08 23:17:18 UTC
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 :)

Comment 6 Kia 2005-02-24 20:01:46 UTC
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)


Comment 7 Bill McGonigle 2005-04-07 13:43:48 UTC
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.

Comment 8 Mark Orenstein 2005-05-02 18:24:11 UTC
Also occurs on Dell Poweredge SC420 and Dell Poweredge 2800 with the 2.6.11-
1.14-FC3smp kernel

Comment 9 Forest Wilkinson 2005-05-03 16:34:06 UTC
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

Comment 10 Patrick Jon Cooney 2005-06-30 17:16:26 UTC
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.

Comment 11 Dave Jones 2005-07-15 20:36:55 UTC
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.

Comment 12 Christophe Lambin 2005-08-16 18:46:06 UTC
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' ?

Comment 13 Rainer Traut 2005-08-20 18:18:01 UTC
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

Comment 14 Graham Hudspith 2005-08-21 00:13:49 UTC
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?

Comment 15 Dave Jones 2005-08-26 08:26:45 UTC
Fixed in CVS, will be in next errata.


Comment 16 Karel Zak 2005-08-30 15:33:15 UTC
*** Bug 164693 has been marked as a duplicate of this bug. ***