Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Strange with hardware clock

New to Debian (Or Linux in general)? Ask your questions here!
Post Reply
Message
Author
User avatar
mertress
Posts: 7
Joined: 2010-01-11 19:18
Location: Russia, Zelenograd

Strange with hardware clock

#1 Post by mertress »

Hi
I just install Debian squeeze/sid on my desktop with KDE.
On each reboot system time adds 3 hours.
My timezone is GMT+3 and hardware clock is set to local time because I use multiboot with Windows.
As I search, in /etc/default/rcS must be UTC=no. But it was and didn't work.
Then I looked in my debian netbook settings and there was UTC=yes. On netbook debian runs about a year without such problems and I never look at these parameters.
After I set UTC=yes on my desktop everything works ok.
But why? :)
I have two machines with correctly working wrong settings?

refracta
Posts: 1234
Joined: 2008-10-26 01:46

Re: Strange with hardware clock

#2 Post by refracta »

is your timezone set correctly?

dpkg-reconfigure tzdata

User avatar
mertress
Posts: 7
Joined: 2010-01-11 19:18
Location: Russia, Zelenograd

Re: Strange with hardware clock

#3 Post by mertress »

refracta wrote:is your timezone set correctly?

dpkg-reconfigure tzdata
I did dpkg-reconfigure tzdata. It's ok.
Output of commands:

Code: Select all

# env LANG=en_EN date
Tue Jan 12 00:20:14 MSK 2010
# env LANG=en_EN date -u
Mon Jan 11 21:20:17 UTC 2010
# env LANG=en_EN hwclock -r
Tue Jan 12 00:20:23 2010  -0.128220 seconds

User avatar
TristanDee
Posts: 64
Joined: 2007-12-11 10:43
Location: Dhaka, Bangladesh
Contact:

Re: Strange with hardware clock

#4 Post by TristanDee »

I also faced a similar situation except for in my case the clock used to go back by six hours to set UTC. I'm in UTC+6 timezone. Occasionally, especially if aptitude upgrade had anything to do with time settings, the clock would go back by six hours.

I don't know if this will work for you--it worked for me. Set the correct time while you are in Debian. Then type in terminal as root

Code: Select all

hwclock --systohc
This is supposed to set system time to the hardware clock. And this should not affect Windows.

After such upgrades I just told about, I get an error during boot-up, saying the last booting time WAS IN THE FUTURE. So I have to login as root and run fsck, which fixes the conflicts.
...Our lives are mostly a constant evasion of ourselves. --TS Eliot
Linux User #501018

User avatar
hazel
Posts: 135
Joined: 2009-08-01 16:34

Re: Strange with hardware clock

#5 Post by hazel »

It's worth checking what time your hardware clock is actually using. You don't always get the correct result from hwclock --show because the system gives you a "corrected" time if it thinks you are running UTC. hwclock --show --debug will give you more information.

User avatar
aspnair
Posts: 1247
Joined: 2009-06-18 12:27
Location: Twitter: @anand_sivaram

Re: Strange with hardware clock

#6 Post by aspnair »

Your UTC and MSK are showing the same time as per your second post.
Try "date -R"
Also you could use "ntpdate" to set time automatically using ntp protocol.
Compressed Air Energy Storage, Entropy and Efficiency
http://saurorja.org/2012/06/18/compress ... fficiency/

User avatar
mertress
Posts: 7
Joined: 2010-01-11 19:18
Location: Russia, Zelenograd

Re: Strange with hardware clock

#7 Post by mertress »

hazel wrote:It's worth checking what time your hardware clock is actually using. You don't always get the correct result from hwclock --show because the system gives you a "corrected" time if it thinks you are running UTC. hwclock --show --debug will give you more information.
You were right. hwclock --debug shows that my real hardware clock was UTC. Thanks :)

Than I go to /etc/default/rcS and set UTC=no. After it I have another bug.
Here is the output. My system time is always hardware clock+3. And hardware clock shows right time. Date shows wrong.
When setting hwclock --hctosys date becomes right but after reboot it's again hwclock+3.

Code: Select all

$ env LANG=en_EN date
Mon Jan 18 04:22:08 MSK 2010

$ env LANG=en_EN hwclock --debug
hwclock from util-linux-ng 2.16.2
Using /dev interface to clock.
Last drift adjustment done at 1263766366 seconds after 1969
Last calibration done at 1263766366 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2010/01/18 01:22:12
Hw clock time : 2010/01/18 01:22:12 = 1263766932 seconds since 1969
Mon Jan 18 01:22:12 2010  -0.606672 seconds
I view logs and found this:

Code: Select all

$ dmesg | grep -i utc
[    0.000000] Linux version 2.6.30-2-amd64 (Debian 2.6.30-8squeeze1) (dannf@debian.org) (gcc version 4.3.4 (Debian 4.3.4-5) ) #1 SMP Mon Dec 7 05:21:45 UTC 2009
[    0.421717] rtc_cmos 00:05: setting system clock to 2010-01-18 01:13:16 UTC (1263777196)
Does this mean than something interpretes hardware clock as UTC?
Looks similar to debian bug 534308 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534308 but I have util-linux 2.16-2.0
aspnair wrote:Your UTC and MSK are showing the same time as per your second post.
Try "date -R"
Also you could use "ntpdate" to set time automatically using ntp protocol.
I don't want to use ntp just now. I want not to simply see correct time but also understand what the problem is :)

User avatar
mertress
Posts: 7
Joined: 2010-01-11 19:18
Location: Russia, Zelenograd

Re: Strange with hardware clock

#8 Post by mertress »

As I understand the problem is kernel option RTC_HCTOSYS=yes. It sets system clock directly from hardware clock on boot.
I also checked that script /etc/init.d/hwclock.sh does nothing because there is no udev

This means that if I recompile kernel with RTC_HCTOSYS=no the system will not update system clock at all?
May be really better to use ntp. I will try later

User avatar
hazel
Posts: 135
Joined: 2009-08-01 16:34

Re: Strange with hardware clock

#9 Post by hazel »

[quote="mertress"]You were right. hwclock --debug shows that my real hardware clock was UTC. Thanks :)

Than I go to /etc/default/rcS and set UTC=no. After it I have another bug.
Here is the output. My system time is always hardware clock+3. And hardware clock shows right time. Date shows wrong.
When setting hwclock --hctosys date becomes right but after reboot it's again hwclock+3.

Code: Select all

$ env LANG=en_EN date
Mon Jan 18 04:22:08 MSK 2010[/quote]
No, you're still confused. Setting UTC=yes or UTC=no doesn't tell your hardware clock what kind of time to use. It just tells the hwclock program how to interpret the figures it finds on the clock. If you want your hardware clock to show local time, you need to do two things:

1) Write UTC=no in rcS so that the system will know that your clock is meant to be using local time, not UTC.
2) Reboot and go into  the BIOS.  Now physically set the hardware clock to show the same time as your local clocks.

When Debian boots, it should set the system time to the actual time on your hardware clock without making any corrections for locale.

User avatar
mertress
Posts: 7
Joined: 2010-01-11 19:18
Location: Russia, Zelenograd

Re: Strange with hardware clock

#10 Post by mertress »

hazel, thank for your answer
Now let's clear some moments
If I right, hardware clock = bios clock. I can set it in bios directly or throuh hwclock tool.

What happens on my machine. I set UTC=no, reboot many times :)
Hwclock tool shows for example that local_time=hw_time=x hours. And date command shows x+3 hours. Moreover each reboot adds 3 hours to both.

The question is: which scripts make correction? I found these answer (correct me if I wrong)
1. When system boots it runs scripts from /etc/rcS. There is hwclock.sh which shoud set system time from hardware clock with correction (depends on UTC=no or UTC=yes). But on my machine it does nothing, I checked.
2. With kernel option RTC_HCTOSYS=yes. Something (I don't know what) sets system clock to hardware clock during boot, because kernel doesn't know about time zone.
3. When shutdown, hwclock.sh runs and sets hardware clock from system time (with or without correction, depends on UTC option).

On my system on boot kernel sets system time to hardware_time+3.
I found this description:
"config RTC_HCTOSYS
If you say yes here, the specified RTC device will be used as a reference to the system time (wall clock). The device will be used to set the system time as required during startup, suspend and, for platforms that support such usage, for NTP timekeeping.

config RTC_HCTOSYS_DEVICE
The RTC device that will be used as a reference for the system clock, usually rtc0. Initialization is done when the system if supported by the platform, NTP timekeeping uses this device to record the system time periodically. This device should record time in UTC, since the kernel won't do timezone correction. "

When I shutdown hwclock.sh records actual system time to hardware (it sees that hardware use local time). Due to system time was previously set to hardware_time+3, hwclock.sh really increments hardware clock for 3 hours. And so each reboot.

P.S. now I installed ntp and happy :)

User avatar
hazel
Posts: 135
Joined: 2009-08-01 16:34

Re: Strange with hardware clock

#11 Post by hazel »

mertress wrote:If I right, hardware clock = bios clock. I can set it in bios directly or throuh hwclock tool.
Correct. I prefer to do this sort of correction in the BIOS. That way I can better see what I'm doing.
What happens on my machine. I set UTC=no, reboot many times :)
Hwclock tool shows for example that local_time=hw_time=x hours. And date command shows x+3 hours. Moreover each reboot adds 3 hours to both.
date always shows the system time. If this is really three hours ahead of the hardware clock, then for some reason your kernel is convinced that your clock is keeping UTC even though you have told it the opposite. I find this rather weird. The three hour shift gets frozen in by the shutdown script as you have surmised in section 3. Hence the ratchet effect that occurs with every reboot.
1. When system boots it runs scripts from /etc/rcS. There is hwclock.sh which shoud set system time from hardware clock with correction (depends on UTC=no or UTC=yes). But on my machine it does nothing, I checked.
What do you mean, it does nothing? What did you check?
2. With kernel option RTC_HCTOSYS=yes. Something (I don't know what) sets system clock to hardware clock during boot, because kernel doesn't know about time zone.
I think this applies to the kernel being able to know the time during boot when it is checking the filesystems. Whatever system time is set by this option should get over-ridden by hwclock.sh. The kernel help notes say that you should only have this option checked if you have an rtc device that uses UTC - which yours doesn't. I wonder if this is the source of all your trouble.

User avatar
mertress
Posts: 7
Joined: 2010-01-11 19:18
Location: Russia, Zelenograd

Re: Strange with hardware clock

#12 Post by mertress »

hazel, yes, it seems that the problem is in kernel option.
And some words about hwclock.sh. I added several debugging strings to test, where it exits.

A piece of code for option "start" from hwclock.sh

Code: Select all

case "$1" in                                                                   
        start)                                                                     
            if [ -d /dev/.udev ]; then                                                               
                return 0                                               -- EXITS HERE            
            fi      


So, it does nothing when udev is present. There are udev rules about hwclock.

Post Reply