LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
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-07-2013, 02:44 AM   #31
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 226Reputation: 226Reputation: 226

Quote:
Originally Posted by GazL View Post
This whole area looks like a big mess. Maybe the latest util-linux might help?
Finally got around to testing this (util-linux is not for the faint hearted) and the problem still occurs so it's not solved with that.
 
Old 10-07-2013, 03:19 AM   #32
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 861

Rep: Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685
Quote:
Originally Posted by wildwizard View Post
Finally got around to testing this (util-linux is not for the faint hearted) and the problem still occurs so it's not solved with that.
The kernel developers believe that this isn't a problem, and I don't think that util-linux could do anything to change it. Well, that wouldn't be a cheap hack.

So, I'll give you the cheap hack here. What activates this kernel feature is starting ntpd. So, if your hardware clock is not using UTC, add a line to the start section of rc.ntpd so that after ntpd is started, the system clock is saved to the hardware clock:

hwclock --localtime --systohc

After that the kernel won't mess with the hardware clock again.
 
4 members found this post helpful.
Old 10-08-2013, 05:48 PM   #33
tux_dude
Member
 
Registered: Dec 2008
Distribution: Slackware64 Current
Posts: 226

Original Poster
Rep: Reputation: 33
Quote:
Originally Posted by volkerdi View Post
The kernel developers believe that this isn't a problem, and I don't think that util-linux could do anything to change it. Well, that wouldn't be a cheap hack.

So, I'll give you the cheap hack here. What activates this kernel feature is starting ntpd. So, if your hardware clock is not using UTC, add a line to the start section of rc.ntpd so that after ntpd is started, the system clock is saved to the hardware clock:

hwclock --localtime --systohc

After that the kernel won't mess with the hardware clock again.
Will this be a standard part of the ntp package?

Here is what I did. I simply copy the entry from rc.0/rc.6 to rc.ntpd to update the hardware clock only if it set to 'localtime'.
Code:
# The kernel is now mocking around with the the hardware clock (wall clock) if
# ntpd is running, so if the hardware clock (wall clock) is set to 'localtime'
# execute hwclock --localtime --systohc to disable the 11 minute mode kernel
# function.
if [ -x /sbin/hwclock ]; then
  # Check for a broken motherboard RTC clock (where ioports for rtc are
  # unknown) to prevent hwclock causing a hang:
  if ! grep -q -w rtc /proc/ioports ; then
    CLOCK_OPT="--directisa"
  fi
  if ! grep -q "^UTC" /etc/hardwareclock 2> /dev/null ; then 
    echo "Saving system time to the hardware clock (localtime)."
    /sbin/hwclock  $CLOCK_OPT --localtime --systohc
  fi
fi
Patch available if anyone needs it.

Last edited by tux_dude; 10-08-2013 at 05:55 PM.
 
Old 10-08-2013, 05:51 PM   #34
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 861

Rep: Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685Reputation: 1685
Quote:
Originally Posted by tux_dude View Post
Here is what I did. I simply copy the entry from rc.0/rc.6 and only update the hardware clock if it set to 'localtime'.
I don't think that will help. The problem isn't with the system clock, it's with the hardware clock. If you have a power failure with the hardware clock set wrong, rc.{0,6} won't have a chance to run and your clock will be wrong on reboot.
 
Old 10-08-2013, 05:56 PM   #35
tux_dude
Member
 
Registered: Dec 2008
Distribution: Slackware64 Current
Posts: 226

Original Poster
Rep: Reputation: 33
I updated my earlier post for clarity. I updated the start section of rc.ntpd as suggested by adding hwclock update from rc.0/rc.6, with minor tweaks.
 
Old 10-08-2013, 06:13 PM   #36
tux_dude
Member
 
Registered: Dec 2008
Distribution: Slackware64 Current
Posts: 226

Original Poster
Rep: Reputation: 33
Patch...

rc.ntpd.patch
Attached Files
File Type: txt rc.ntpd.patch.txt (928 Bytes, 20 views)
 
Old 10-10-2013, 01:23 PM   #37
GazL
Senior Member
 
Registered: May 2008
Posts: 3,380

Rep: Reputation: 913Reputation: 913Reputation: 913Reputation: 913Reputation: 913Reputation: 913Reputation: 913Reputation: 913
While we're on the subject of the system clock, I believe the clock setting code in rc.S can be simplified significantly with modern kernels and util-linux. The following seems to be all that is needed:
Code:
# Time-warp the system clock to correct for a CMOS/Hardware Clock
# that is running in 'localtime'.  It's just a jump to the left...
echo "Time-warp the system clock: /sbin/hwclock --systz"
/sbin/hwclock --systz
echo "System Time: $(date)"
It appears that on x86 the kernel automatically loads the CMOS clock even without CONFIG_RTC_HCTOSYS.

From what I've read this is particularly desirable to those who run VM instances as hwclock --hctosys calls can be slow in a VM (or so I've read).

Anyway, seems to work for me, but someone with a slightly greater offset from UTC might want to give it a test.
Attached Files
File Type: txt rc.S-clock.patch.txt (1.1 KB, 6 views)

Last edited by GazL; 10-10-2013 at 01:27 PM.
 
Old 10-12-2013, 05:29 PM   #38
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 226Reputation: 226Reputation: 226
Quote:
Originally Posted by volkerdi View Post
After that the kernel won't mess with the hardware clock again.
Well after trying this for a few days it seems that that wont even stop it.
 
Old 10-16-2013, 08:57 PM   #39
tux_dude
Member
 
Registered: Dec 2008
Distribution: Slackware64 Current
Posts: 226

Original Poster
Rep: Reputation: 33
After leaving this for a few days, it seem running hwclock does not disable to 11 minute mode. The only way I found to turn this off was to shut down NTP. IMO, disabling NTP is not an option. I have since removed the rc.ntp patch.
 
Old 10-17-2013, 03:02 AM   #40
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 226Reputation: 226Reputation: 226
tux_dude the patch I provided earlier for the kernel does remove the offending code and fixes the problem properly.

This is the way I'm now running and will continue to do so.
 
Old 10-22-2013, 07:34 AM   #41
GazL
Senior Member
 
Registered: May 2008
Posts: 3,380

Rep: Reputation: 913Reputation: 913Reputation: 913Reputation: 913Reputation: 913Reputation: 913Reputation: 913Reputation: 913
Do we have a better feel for this yet? In testing my experience was the same as tux_dude: that the rc.ntpd change has had no effect on 11 minute mode. If this code is indeed not making any difference then it's probably best to revert it and strip out some unneeded complexity in the rc.ntpd file.

If the new code is indeed working for some people, then may I suggest a minor reordering for the sake of efficiency in the case that the hardware clock is running UTC.

Code:
--- rc.ntpd.orig        2013-10-22 13:15:07.026378761 +0100
+++ rc.ntpd     2013-10-22 13:19:30.217014427 +0100
@@ -11,13 +11,13 @@
   # ntpd is running, so if the hardware clock (wall clock) is set to
   # 'localtime' execute hwclock --localtime --systohc to disable the
   # 11 minute mode kernel function:
-  if [ -x /sbin/hwclock ]; then
-    # Check for a broken motherboard RTC clock (where ioports for rtc are
-    # unknown) to prevent hwclock causing a hang:
-    if ! grep -q -w rtc /proc/ioports ; then
-      CLOCK_OPT="--directisa"
-    fi
-    if ! grep -q "^UTC" /etc/hardwareclock 2> /dev/null ; then 
+  if ! grep -q "^UTC" /etc/hardwareclock 2> /dev/null ; then 
+    if [ -x /sbin/hwclock ]; then
+      # Check for a broken motherboard RTC clock (where ioports for rtc are
+      # unknown) to prevent hwclock causing a hang:
+      if ! grep -q -w rtc /proc/ioports ; then
+        CLOCK_OPT="--directisa"
+      fi
       echo "Saving system time to the hardware clock (localtime)."
       /sbin/hwclock  $CLOCK_OPT --localtime --systohc
     fi
 
1 members found this post helpful.
Old 12-06-2013, 11:01 PM   #42
tux_dude
Member
 
Registered: Dec 2008
Distribution: Slackware64 Current
Posts: 226

Original Poster
Rep: Reputation: 33
I've conceded, switched my hardware clock on systems not on UPS to UTC.
 
  


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 11:26 AM
hardware clock time differs from system time after setting maxgsp Linux - Software 2 02-28-2009 07:15 AM
hardware clock time differs from system time after setting maxgsp Linux - Hardware 1 02-27-2009 05:24 AM
Benefit of NOT using UTC on the hardware clock? daihard Linux - General 1 02-09-2008 09:16 AM
Where does RH8 daily set system time to hardware clock time smartnorman Red Hat 1 05-24-2006 02:42 PM


All times are GMT -5. The time now is 09:38 AM.

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