SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
It seems CONFIG_RTC_SYSTOHC was added somewhere in linux-3.9-stable and the default "y" was missed in linux-3.10.17 of Slackware 14.1, probably by accident. I think before that the eleven minute mode could not be switched off.
Last edited by Petri Kaukasoina; 02-01-2022 at 10:11 AM.
I have a vague recollection that on a PC there's a distinction between RTC hardware and the CMOS clock, and so this option is unneeded unless you have separate clock hardware installed that you wish to use.
I have a vague recollection that on a PC there's a distinction between RTC hardware and the CMOS clock, and so this option is unneeded unless you have separate clock hardware installed that you wish to use.
It's been a while though, so I could be wrong.
You are right.
Code:
linux root ~ # /etc/rc.d/rc.ntpd stop
Stopping NTP daemon...
linux root ~ # date -s 'Tue Feb 1 21:57:15 EET 2022'
Tue Feb 1 21:57:15 EET 2022
linux root ~ # hwclock --systohc (a wrong time to cmos clock)
linux root ~ # date -s 'Tue Feb 1 21:50:15 EET 2022' (another time to system clock)
Tue Feb 1 21:50:15 EET 2022
linux root ~ # hwclock --show; date
Tue Feb 1 21:57:27 2022 .541702 seconds (cmos clock)
Tue Feb 1 21:50:20 EET 2022 (system clock)
linux root ~ # /etc/rc.d/rc.ntpd start
Starting NTP daemon: /usr/sbin/ntpd -g
linux root ~ # hwclock --show; date
Tue Feb 1 21:57:39 2022 .963547 seconds
Tue Feb 1 21:50:32 EET 2022
linux root ~ # hwclock --show; date
Tue Feb 1 21:57:46 2022 .791700 seconds
Tue Feb 1 22:09:34 EET 2022 (now ntp synced system clock)
linux root ~ # hwclock --show; date
Tue Feb 1 22:11:26 2022 .838619 seconds (now 11-minute mode fixed cmos)
Tue Feb 1 22:11:27 EET 2022
It occurred to me at random that this change to RTC_SYSTOHC=y might work differently (or not work, as the case may be) depending on if the system's hardware clock is storing local time or UTC. And then it all came back to me and I found the old thread.
I'm not sure what the great benefit is of having the kernel mess with the hardware clock automatically. For that matter, I'm not sure what I was doing in this here thread. ;-)
I'm rolling it back to "RTC_SYSTOHC is not set" which without significant further testing seems like the safe plan.
The RTC emulation option will be left off though as that seems pretty clearly bogus.
I'm rolling it back to "RTC_SYSTOHC is not set" which without significant further testing seems like the safe plan.
Agreed.
It's always best to run the hardware clock in UTC. BTW, in this post https://www.linuxquestions.org/quest...ml#post5043528 GazL mentions 'hwclock --systz' which can be used to tell the kernel which local timezone is in use instead of UTC. After it, the 11-minute mode writes the correct local time in cmos, but after a change to/from DST, it will be off again unless run again.
yes, that looks to do the same thing, though unlike --systz it goes out of its way to avoid timewarp semantics and I can't see why you'd really want that. Timewarp only occurs on the first call, and it's something you probably want to lock down on boot to prevent a subsequent call from doing it.
Personally, I still favour --systz over --hctosys in rc.S. The downside is that it doesn't apply drift correction, but I suspect no one uses that anyway.
For that matter, I'm not sure what I was doing in this here thread. ;-)
I'm rolling it back to "RTC_SYSTOHC is not set" which without significant further testing seems like the safe plan.
The RTC emulation option will be left off though as that seems pretty clearly bogus.
(emphasis added by me)
Yes, I posted in this thread to avoid causing problems for the upcoming 15.0 release. Sorry for causing a mini-firestorm.
As I posted above, running current (Tue Feb 1 08:27:47 UTC 2022) I saw 11-minute mode active (while running ntpd). So it seems the help text for RTC_SYSTOHC is misleading. The linked thread (https://www.linuxquestions.org/quest...me-4175477525/) has some good information.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
