Bugzilla Bug 212588

After I upgraded from sys-kernel/tuxonice-sources-2.6.23-r10 to
sys-kernel/tuxonice-sources-2.6.24-r3 the daemon /etc/init.d/clockd started to
require '--directisa' option for hwclock to run. I haven't tried it with other
sources but AFAIK th ArchLinux and Debian are having the same problem.

Reproducible: Always




The ArchLinux devs speculated tha it might have something to do with the old
charecter divece rtc support, the new rtc_cmos (but not that old mistake of
switching them both on)  and the order of boot init scripts.
Workaround: use --directisa in hwclock opts in /etc/conf.d/clock

Created an attachment (id=145489) [details]
My kernel's .config 

(In reply to comment #0)
> After I upgraded from sys-kernel/tuxonice-sources-2.6.23-r10 to
> sys-kernel/tuxonice-sources-2.6.24-r3 the daemon /etc/init.d/clockd started to
> require '--directisa' option for hwclock to run. I haven't tried it with other
> sources but AFAIK th ArchLinux and Debian are having the same problem.

Please try with vanilla-sources. From what you wrote it looks like a generic
(not tuxonice related) problem.

The same thing with sys-kernel/vanilla-sources-2.6.24.3.

Created an attachment (id=145535) [details]
The vanilla-sources' .config

Same with vanilla-sources

Please detail what happens when you don't run with --directisa

Same problem here with 2.6.24 kernel series, both gentoo-sources and vanilla

 * Setting system clock using the hardware clock [UTC] ...
 * select() to /dev/rtc to wait for clock tick timed outselect() to /dev/rtc to
wait for clock tick timed out
 * Failed to set clock You will need to set the clock yourself                 
                                          [ !! ]

The same happens if hwclock is run from the command line.
$ hwclock
select() to /dev/rtc to wait for clock tick timed out

However after starting some programs (not clear which ones), hwclock starts
working on a switch basis. i.e. sometimes works sometimes doesn't. Usually it
works more times than it fails.
However in the shutdown process, since most of the programs are terminated
before running the clock script, system clock and hardware clock always seem to
fail.

By passing the --directisa option it works without errors.

Hello all,

I've fixed this on my laptop by using HPET instead of RTC.
HPET should be the future replacement for RTC and is available
on newer computers.

For enabling HPET you'll need CONFIG_HPET and CONFIG_HPET_TIMER set.
For replacing RTC you'll need CONFIG_HPET_EMULATE_RTC .

I hope this helps.

can anyone else confirm that?

I had a little trouble finding and activating the option
CONFIG_HPET_EMULATE_RTC using menuconfig. Basically what you need is to set RTC
built-in and not as module. CONFIG_HPET_EMULATE_RTC will be set to Y
automatically if CONFIG_HPET is also defined.

After activating this option, the '--directisa' is no longer required.

(In reply to comment #9)
> I had a little trouble finding and activating the option
> CONFIG_HPET_EMULATE_RTC using menuconfig. Basically what you need is to set RTC
> built-in and not as module. CONFIG_HPET_EMULATE_RTC will be set to Y
> automatically if CONFIG_HPET is also defined.
> 
> After activating this option, the '--directisa' is no longer required.
> 
This works but then you won't be able to use the new RTC susbsystem in "Device
Drivers/Real Time Clock" because it conflicts with "Character devices/Extended
RTC support" which seems to be the old way of doing things.

I have found a new interesting detail about this bug: when after booting I run
'hwclock --hctosys' I get no error. However if i quickly type in a few
subsequent 'hwclock --hctosys' I get exactly the same error as the one given by
init script namely "select() to /dev/rtc0 to wait for clock tick timed out".
And if I restart the clock service manually '/etc/init.d/clock restart' I get
this error regardlessly of how often I run it or what were previous comands or
anything else. It appears that syncing with the clock makes it very busy and
unable to handle subsequent calls for a while. The questions are: what in the
boot init script makes the clock so busy as in my little experiment and why
this problem didn't show up in 2.6.23. Remember, I'm using the newer Real Time
Clock kernelfacility, not the one in Character devices.

An certainly when I tried 'hwclock --hctosys --directisa' I haven't managed to
spit out these comands quickly enough to make hwclock complain.

I had the same problem.
Adding "--directisa" in hwclock opts in /etc/conf.d/clock solves the problem.

I have this error on 3 computers I have.

(In reply to comment #8)
> can anyone else confirm that?
> 
looks summary should be changed to "select() to /dev/rtc to wait for clock tick
timed out" or something /etc/init.d/clock or hwclock related.

This was my problem after moving system from Sempron 3000+ (single core) to
Core2Duo (Dual Core).

Old config was:

CONFIG_RTC=m                             - <M> Enhanced Real Time Clock Support
# CONFIG_GEN_RTC is not set              - < > Generic /dev/rtc emulation
# CONFIG_RTC_CLASS is not set

It worked on single core but on C2D hwclock gave "select() to /dev/rtc to wait
for clock tick timed"

These kernel options resolved this issue:

# CONFIG_RTC is not set
# CONFIG_GEN_RTC is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET=y
CONFIG_HPET_RTC_IRQ=y
CONFIG_HPET_MMAP=y
CONFIG_RTC_LIB=m
CONFIG_RTC_CLASS=m
# RTC interfaces
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
# SPI RTC drivers
# Platform RTC drivers
CONFIG_RTC_DRV_CMOS=m
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_V3020 is not set

in menuconfig terms:

Device Drivers  ---> Character devices  --->
< > Enhanced Real Time Clock Support
< > Generic /dev/rtc emulation
[*] HPET - High Precision Event Timer
[*]   HPET Control RTC IRQ
[*]   Allow mmap of HPET

Device Drivers  ---> <M> Real Time Clock  --->
[*]   /sys/class/rtc/rtcN (sysfs)
[*]   /proc/driver/rtc (procfs for rtc0)
[*]   /dev/rtcN (character devices)
[ ]     RTC UIE emulation on dev interface
<M>   PC-style 'CMOS'

Disclaimer: I'm not an expert - may be not all my options are needed, 
e.g. "<M>   PC-style 'CMOS'" generates rtc-cmos module, which is not loaded on
my system.

BTW --directisa is unnecessary

The kernel in 2.6.25 the bug is gone.

(In reply to comment #7)
> Hello all,
> 
> I've fixed this on my laptop by using HPET instead of RTC.
> HPET should be the future replacement for RTC and is available
> on newer computers.

i have 2.6.24-r4 running on my acer extensa 4620 laptop.
I've managed to fix the problem by compiling rtc into kernel, instead of
module.
This if from help to CONFIG_RTC:
If you run Linux on a multiprocessor machine and said Y
to "Symmetric Multi Processing" above, you should say Y here to read and set
the RTC in an SMP compatible fashion.
So i suppose it's not a bug :)