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 attachment 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 attachment 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 :)
i just ran into this, or something that exhibits these symptoms, with 3.0 series. after noticing this acer travelmate 8172 i3 laptop all of a sudden would stop time whenever suspended or powered off, i eventually also tried going back to CONFIG_RTC. after finding [1], i thought i'd give resetting BIOS a try. arriving in BIOS i noticed the time shown there was off for even UTC, so i set it right, and saved the result - i.e. did not even do a complete "load defaults". after next boot, hwclock -r now seems to work without issues and testing suspend also resulted in correct time after resume. hopefully problem solved. [1]: http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-01/msg01326.html
(In reply to comment #17) > going back to CONFIG_RTC. after finding [1], i thought i'd give resetting BIOS i wanted to say going back to CONFIG_RTC did not help, either. my post-BIOS-fixed configuration is on the new-style RTC class.
