LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 10-01-2013, 07:14 PM   #16
tux_dude
Member
 
Registered: Dec 2008
Distribution: Slackware64 Current
Posts: 226

Original Poster
Rep: Reputation: 33

Quote:
Originally Posted by Richard Cranium View Post
How about...

Code:
ps -ef | grep ntpd
Yes, I do have ntpd running. It keeps the system time (DATE: from my above output) in sync.

Code:
ps -ef | grep ntpd
root      5613     1  0 Sep30 ?        00:00:08 /usr/sbin/ntpd -g -p /var/run/ntpd.pid
Quote:
Originally Posted by Richard Cranium View Post
...and...

Code:
grep ntp /etc/dhcpcd.conf
...? What do those two commands give?
Code:
grep ntp /etc/dhcpcd.conf
option ntp_servers
 
Old 10-01-2013, 07:35 PM   #17
tux_dude
Member
 
Registered: Dec 2008
Distribution: Slackware64 Current
Posts: 226

Original Poster
Rep: Reputation: 33
Quote:
Originally Posted by GazL View Post
One of the recent kernels introduced these new options, which sound as if they may be relevant.

CONFIG_RTC_HCTOSYS:
If you say yes here, the system time (wall clock) will be set using the value read from a specified RTC device. This is useful to avoid unnecessary fsck runs at boot time, and to network better.

CONFIG_RTC_SYSTOHC:
If you say yes here, the system time (wall clock) will be stored in the RTC specified by RTC_HCTOSYS_DEVICE approximately every 11 minutes if userspace reports synchronized NTP status.

Also check out the help text on CONFIG_RTC_HCTOSYS_DEVICE:
This device should record time in UTC, since the kernel won't do timezone correction


If you're running your hw_clock on localtime then you probably want to avoid these new RTC options in your kernel config (especially the second one).

P.S. Both appear to be set to Y in config-generic-3.10.12.x64
This is interesting. If I read it correctly, it looks like I'm probably being affected by CONFIG_RTC_SYSTOHC, since this cause the RTC (BIOS) clock to be updated every 11 minutes.

I couldn't find any option to disable this feature without recompiling the kernel. I am not a fan of building my own kernel as it is too much maintenance work for me. What are other who are not affected doing?
 
2 members found this post helpful.
Old 10-01-2013, 08:54 PM   #18
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 875

Rep: Reputation: 1823Reputation: 1823Reputation: 1823Reputation: 1823Reputation: 1823Reputation: 1823Reputation: 1823Reputation: 1823Reputation: 1823Reputation: 1823Reputation: 1823
Quote:
Originally Posted by tux_dude View Post
This is interesting. If I read it correctly, it looks like I'm probably being affected by CONFIG_RTC_SYSTOHC, since this cause the RTC (BIOS) clock to be updated every 11 minutes.

I couldn't find any option to disable this feature without recompiling the kernel. I am not a fan of building my own kernel as it is too much maintenance work for me. What are other who are not affected doing?
Well, I'm assuming that GazL has nit the nail on the head as usual, and will remove those options from the 3.10.14 kernels. Test 'em when they go up... shouldn't be long.
 
4 members found this post helpful.
Old 10-02-2013, 03:56 AM   #19
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 227Reputation: 227Reputation: 227
I hope that does fix it Pat as I just got hit by this little kernel addition and if you also run your own DNS as I do dnssec will fall in a heap and it is pretty much a requirement these days.
 
Old 10-02-2013, 04:33 AM   #20
GazL
Senior Member
 
Registered: May 2008
Posts: 3,481

Rep: Reputation: 1016Reputation: 1016Reputation: 1016Reputation: 1016Reputation: 1016Reputation: 1016Reputation: 1016Reputation: 1016
I'd encourage folks to run their hw clock on UTC if at all possible and only use 'localtime' if absolutely necessary. It's clearly the way the system is intended to be used and avoids these sorts of issues.

If you dual-boot with Windows there's a registry entry you can change to make it also treat the hardware clock as UTC which is what I've done here.

Last edited by GazL; 10-02-2013 at 04:37 AM.
 
2 members found this post helpful.
Old 10-02-2013, 06:53 AM   #21
allend
Senior Member
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 3,485

Rep: Reputation: 856Reputation: 856Reputation: 856Reputation: 856Reputation: 856Reputation: 856Reputation: 856
Quote:
CONFIG_RTC_SYSTOHC:
If you say yes here, the system time (wall clock) will be stored in the RTC specified by RTC_HCTOSYS_DEVICE approximately every 11 minutes if userspace reports synchronized NTP status.
I am going to point the finger at this setting. On my system that dual boots to Windows, I have the hardware clock set to local time, but I do not use NTP (I let Windows do the time synchronisation). I have not seen this issue.
 
Old 10-02-2013, 12:58 PM   #22
chrisretusn
Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware
Posts: 491

Rep: Reputation: Disabled
It does seem to be the issue. I switched to running all of my systems using UTC for the hardware clock a while ago using similar logic as Gazl.
 
Old 10-02-2013, 08:59 PM   #23
tux_dude
Member
 
Registered: Dec 2008
Distribution: Slackware64 Current
Posts: 226

Original Poster
Rep: Reputation: 33
I wouldn't call it necessary, however I would rather have my hardware clock set to localtime. Since the kernel does not do localtime, then this option should read:
Quote:
CONFIG_RTC_SYSTOHC:
If you say yes here, the system time (wall clock) will be stored in the RTC specified by RTC_HCTOSYS_DEVICE approximately every 11 minutes if the system time (wall clock) is set to UTC and the userspace reports synchronized NTP status.

Last edited by tux_dude; 10-02-2013 at 10:46 PM.
 
Old 10-04-2013, 07:57 AM   #24
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 227Reputation: 227Reputation: 227
Running the new kernel and the new options are right :-
Code:
root@indigo:/proc# zcat config.gz | grep RTC
CONFIG_HPET_EMULATE_RTC=y
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_SYSTOHC is not set
But it still happens :-
Code:
Fri Oct  4 21:46:34 EST 2013
Fri 04 Oct 2013 21:46:35 EST  -0.986628 seconds
Fri Oct  4 21:47:35 EST 2013
Fri 04 Oct 2013 21:47:36 EST  -1.001941 seconds
Fri Oct  4 21:48:36 EST 2013
Fri 04 Oct 2013 11:48:37 EST  -0.955072 seconds
Fri Oct  4 21:49:37 EST 2013
Fri 04 Oct 2013 11:49:38 EST  -1.001944 seconds
EDIT

Pulled the code from the kernel it it is :-
Code:
#if defined(CONFIG_GENERIC_CMOS_UPDATE) || defined(CONFIG_RTC_SYSTOHC)
So we have one more option to kill

EDIT2

Remove the offending config setting which is actually deprecated, the new option we've been talking about replaces this one

Code:
--- arch/x86/Kconfig.old        2013-10-04 22:47:31.925835050 +1000
+++ arch/x86/Kconfig    2013-10-04 22:47:40.047548184 +1000
@@ -101,7 +101,6 @@
        select ARCH_WANT_IPC_PARSE_VERSION if X86_32
        select HAVE_ARCH_SECCOMP_FILTER
        select BUILDTIME_EXTABLE_SORT
-       select GENERIC_CMOS_UPDATE
        select CLOCKSOURCE_WATCHDOG
        select GENERIC_CLOCKEVENTS
        select ARCH_CLOCKSOURCE_DATA if X86_64

Last edited by wildwizard; 10-04-2013 at 08:51 AM.
 
Old 10-04-2013, 08:49 AM   #25
bartgymnast
Member
 
Registered: Feb 2003
Location: Lelystad, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 269

Rep: Reputation: 93
Hi All,

grabbed this part from arch linux

Recent kernels set the system time from the RTC directly on boot, assuming that the RTC is in UTC. This means that if the RTC is in local time, then the system time will first be set up wrongly and then corrected shortly afterwards on every boot. This is the root of certain weird bugs (time going backwards is rarely a good thing).

These will generate /etc/adjtime automatically; no further configuration is required.

During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs or not depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of /sys/class/rtc/rtcN/hctosys (N=0,1,2,..) will be set to 1. Later, the system clock is set again from the hardware clock from systemd/udev, dependent on values in /etc/adjtime. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea.

so indeed the option of wildwizard is the other option that needs to be killed

Last edited by bartgymnast; 10-04-2013 at 08:50 AM.
 
Old 10-04-2013, 08:53 AM   #26
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 227Reputation: 227Reputation: 227
Quote:
Originally Posted by bartgymnast View Post
Recent kernels set the system time from the RTC directly on boot
We already have code in rc.S to set the system clock, having the kernel suddenly start butting in is not a good idea.
 
2 members found this post helpful.
Old 10-04-2013, 09:40 AM   #27
allend
Senior Member
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 3,485

Rep: Reputation: 856Reputation: 856Reputation: 856Reputation: 856Reputation: 856Reputation: 856Reputation: 856
From 'man hwclock' (Bold emphasis is mine)
Code:
Automatic Hardware Clock Synchronization By the Kernel
       You should be aware of another way that the Hardware Clock is kept synchronized in some systems.  The Linux kernel has a mode
       wherein it copies the System Time to the Hardware Clock every 11 minutes.  This is a good mode to  use  when  you  are  using
       something  sophisticated  like ntp to keep your System Time synchronized. (ntp is a way to keep your System Time synchronized
       either to a time server somewhere on the network or to a radio clock hooked up to your system.  See RFC 1305).

       This mode (we'll call it "11 minute mode") is off until something turns it on.  The ntp daemon xntpd is one thing that  turns
       it  on.   You  can  turn it off by running anything, including hwclock --hctosys, that sets the System Time the old fashioned
       way.

       To see if it is on or off, use the command adjtimex --print and look at the value of "status".  If the "64" bit of this  num-
       ber (expressed in binary) equal to 0, 11 minute mode is on.  Otherwise, it is off.

       If your system runs with 11 minute mode on, don't use hwclock --adjust or hwclock --hctosys.  You'll just make a mess.  It is
       acceptable to use a hwclock --hctosys at startup time to get a reasonable System Time until your system is able  to  set  the
       System Time from the external source and start 11 minute mode.
Is something going on that is turning "11 minute mode" off?
 
Old 10-04-2013, 11:02 AM   #28
allend
Senior Member
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 3,485

Rep: Reputation: 856Reputation: 856Reputation: 856Reputation: 856Reputation: 856Reputation: 856Reputation: 856
I have been looking at /usr/src/linux/kernel/time/ntp.c
As I read it, if you turn off both CONFIG_GENERIC_CMOS_UPDATE and CONFIG_RTC_SYSTOHC, then the "11 minute mode" will be entirely turned off.
 
1 members found this post helpful.
Old 10-04-2013, 12:49 PM   #29
GazL
Senior Member
 
Registered: May 2008
Posts: 3,481

Rep: Reputation: 1016Reputation: 1016Reputation: 1016Reputation: 1016Reputation: 1016Reputation: 1016Reputation: 1016Reputation: 1016
Yep it looks like the new RTC stuff is only part of the story and there's a second mechanism at play here.
Here's some background info I stumbled upon: https://lkml.org/lkml/2013/4/23/690

The interesting thing is that ntp.c contains this:
Code:
        getnstimeofday(&now);
        if (abs(now.tv_nsec - (NSEC_PER_SEC / 2)) <= tick_nsec / 2) {
                struct timespec adjust = now;

                fail = -ENODEV;
                if (persistent_clock_is_local)
                        adjust.tv_sec -= (sys_tz.tz_minuteswest * 60);
#ifdef CONFIG_GENERIC_CMOS_UPDATE
                fail = update_persistent_clock(adjust);
#endif
#ifdef CONFIG_RTC_SYSTOHC
                if (fail == -ENODEV)
                        fail = rtc_set_ntp_time(adjust);
#endif
... which looks like it should still deal with a clock in localtime assuming persistent_clock_is_local and sys_tz are being set correctly.

This whole area looks like a big mess. Maybe the latest util-linux might help?, but to be honest I'm inclined to go back to my previous suggestion which echoes one of the comments in kernel/time.c:
Code:
 
 *The best thing to do is to keep the CMOS clock in universal time (UTC)
 * as real UNIX machines always do it. This avoids all headaches about
 * daylight saving times and warping kernel clocks.
 */
 
3 members found this post helpful.
Old 10-04-2013, 01:09 PM   #30
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware: 12.1, 13.1, 14.1, 64-14.1, -current, FreeBSD-10
Posts: 2,029

Rep: Reputation: 802Reputation: 802Reputation: 802Reputation: 802Reputation: 802Reputation: 802Reputation: 802
I just encountered this on a -current machine after overnight extended power failure.

Nothing new to offer, but thanks for all who have posted - gives me an easier start!

Last edited by astrogeek; 10-04-2013 at 01:12 PM.
 
  


Reply

Tags
bios clock, clock, hardware clock, time, utc


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Clock on wrong time (system clock is set to UTC) yanom Debian 6 07-26-2011 12:26 PM
hardware clock time differs from system time after setting maxgsp Linux - Software 2 02-28-2009 08:15 AM
hardware clock time differs from system time after setting maxgsp Linux - Hardware 1 02-27-2009 06:24 AM
Benefit of NOT using UTC on the hardware clock? daihard Linux - General 1 02-09-2008 10:16 AM
Where does RH8 daily set system time to hardware clock time smartnorman Red Hat 1 05-24-2006 03:42 PM


All times are GMT -5. The time now is 05:36 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration