linux-rtc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Finn Thain <fthain@telegraphics.com.au>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
	userm57@yahoo.com, linux-rtc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rtc: Don't state that the RTC holds UTC in case it doesn't
Date: Tue, 25 Jun 2019 11:29:26 +0200	[thread overview]
Message-ID: <20190625092926.GE5690@piout.net> (raw)
In-Reply-To: <alpine.LNX.2.21.1906251043050.8@nippy.intranet>

On 25/06/2019 11:53:49+1000, Finn Thain wrote:
> On Mon, 24 Jun 2019, Alexandre Belloni wrote:
> 
> > On 21/06/2019 11:51:26+1000, Finn Thain wrote:
> > > Some machines store local time in the Real Time Clock. The hard-coded 
> > > "UTC" string is wrong on those machines so just omit that string. 
> > > Update the log parser so it doesn't require the string "UTC".
> > > 
> > 
> > I don't agree, hctossys will always think the RTC is in UTC.
> 
> Well, I wasn't speculating about a theoretical problem. This is a bug that 
> was reported to me by a user of Debian/powerpc system.
> 
> I was able to confirm that the bug also affects dual-boot Windows/Linux on 
> x86 with CONFIG_RTC_HCTOSYS=y.
> 
> > If you store local time in the RTC, then you are probably not using 
> > hctosys because it definitively doesn't know about the timezone and will 
> > incorrectly set the system time. That information is usually kept in 
> > /etc/adjtime.
> > 
> 
> In the Debian/powerpc bug report, the timezone is obtained from the NVRAM:
> 
> [    0.000000] PowerMac motherboard: PowerBook Wallstreet
> ...
> [    0.000000] GMT Delta read from XPRAM: -360 minutes, DST: on
> ...
> [   37.605859] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
> ...
> [   40.346255] rtc-generic rtc-generic: setting system clock to 2019-06-19 15:17:35 UTC (1560957455)
> ...
> 
> Though I don't know whether the sys_tz value is relevant here.
> 
> Anyway, here's the bug reproduced on x86 --
> 
> # dmesg | grep rtc_cmos
> [    0.543878] rtc_cmos 00:02: RTC can wake from S4
> [    0.544090] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
> [    0.544090] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
> [    0.545807] rtc_cmos 00:02: setting system clock to 2019-06-25 11:24:14 UTC (1561461854)
> # grep . /etc/adjtime /etc/timezone
> /etc/adjtime:0.000120 1550184138 0.000000
> /etc/adjtime:1550184138
> /etc/adjtime:LOCAL
> /etc/timezone:Australia/Melbourne
> # hwclock --show
> 2019-06-25 11:47:49.702660+10:00
> # date --iso-8601=s
> 2019-06-25T11:48:01+10:00
> # 
> 
> Looks wrong to me. What am I missing?
> 

Userspace is certainly adjusting the timezone after the kernel did. Can
you run the same commands without running your init? 

On stable, you have /etc/init.d/hwclock.sh that still runs and does the
correct thing. My understanding is that systemd also handles the TZ
properly after hctosys (see clock_is_localtime()).

Seriously, hctosys does a really bad job at setting the system time, it
is guaranteed to be always wrong on most platforms. My plan is still to
try to get distros to stop enabling it and do that properly in
userspace. This is already ok when using sysV but systemd would need a
few changes to stop relying on it when then is no hwclock initscript.
Unfortunately, I didn't have time to work on that yet.



-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2019-06-25  9:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-21  1:51 [PATCH] rtc: Don't state that the RTC holds UTC in case it doesn't Finn Thain
2019-06-24 19:57 ` Alexandre Belloni
2019-06-25  1:53   ` Finn Thain
2019-06-25  9:29     ` Alexandre Belloni [this message]
2019-06-25 17:16       ` Trent Piepho
2019-06-25 19:19         ` Alexandre Belloni
2019-06-25 20:27           ` Trent Piepho
2019-06-26  4:42       ` Finn Thain
2019-07-13 20:50         ` Alexandre Belloni
2019-07-14  1:17           ` Finn Thain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190625092926.GE5690@piout.net \
    --to=alexandre.belloni@bootlin.com \
    --cc=a.zummo@towertech.it \
    --cc=fthain@telegraphics.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=userm57@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).