Linux-RTC Archive on lore.kernel.org
 help / color / Atom feed
From: Finn Thain <fthain@telegraphics.com.au>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
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: Sun, 14 Jul 2019 11:17:47 +1000 (AEST)
Message-ID: <alpine.LNX.2.21.1907141013360.8@nippy.intranet> (raw)
In-Reply-To: <20190713205014.GC4732@piout.net>

On Sat, 13 Jul 2019, Alexandre Belloni wrote:

> On 26/06/2019 14:42:31+1000, Finn Thain wrote:
> > > Userspace is certainly adjusting the timezone after the kernel did. 
> > > Can you run the same commands without running your init?
> > > 
> > 
> > Sure. I booted into /bin/sh instead of /sbin/init then mounted /proc 
> > and /dev, and got this:
> > 
> > # dmesg | grep rtc_cmos
> > [    0.544046] rtc_cmos 00:02: RTC can wake from S4
> > [    0.544246] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
> > [    0.544246] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
> > [    0.545514] rtc_cmos 00:02: setting system clock to 2019-06-26 14:19:40 UTC (1561558780)
> > # 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-26 14:22:25.437089+10:00
> > # date --iso-8601=s
> > 2019-06-27T00:22:45+10:00
> > 
> > As expected, the kernel message still agrees with the output from 
> > hwclock.
> > 
> 
> hwclock has the information that the RTC is in localtime

Right. From the man page:

          The time shown is always in local time, even if you keep your 
          Hardware Clock in UTC.

The output from hwclock is fine, the output from the kernel is confusing.

> but hctosys correctly set the system time to 2019-06-26T14:19:40+00:00, 
> that is 2019-06-27T00:19:40+10:00 so the kernel message is right and the 
> system time is wrong, unless you invoke hwclock -s
> 

I would not say, "correctly set". The system time is wrong here.

> > > 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()).
> > > 
> > 
> > This was Gentoo/x86 with openrc. The Debian/powerpc problem is exactly 
> > the same: the kernel messages report local time whilst claiming that 
> > it's UTC.
> > 
> 
> That is not what it is reporting, it is reporting that it is setting the 
> system time, thinking that the RTC is in UTC time. Your test shows that 
> this is what happens on x86.
> 

Thanks for your explanation. Please disregard my patch. I see that the 
printk is sensible (i.e. the system clock value is printed in UTC) even 
though the system clock value itself is bogus (up until the init scripts 
fix it).

> > > 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.
> > > 
> > 
> > It doesn't help if you are able to change all of the future distros. 
> > If you remove hctosys you will break some distros which have already 
> > shipped.
> > 
> > For example, I've seen a Debian release that will force a fsck of the 
> > root filesystem without CONFIG_RTC_HCTOSYS. This is a temporary denial 
> > of service not a failure, but in general a backward jump by a few 
> > hours can have bad consequences, such as services that refuse to 
> > start.
> > 
> > Anyway, this bug is about a misleading printk, it isn't about removing 
> > functionality. Why conflate these two issues?
> 
> Again, your test shows that I'm correct and hctosys is setting the 
> system time using the RTC time as UTC time. This gets fixed later by 
> userspace.
> 
> PowerPC is the only different platform because it is able to set sys_tz. 
> It is the only platform doing so. What you can do is check 
> sys_tz.tz_minuteswest, keep UTC if it is 0 and print the timezone if it 
> is not.
> 

If userland is responsible for setting sys_tz.tz_minuteswest then we 
probably should not rely on it here.

PowerMacs may set sys_tz.tz_minuteswest because the NVRAM on that platform 
contains the GMT Bias, thanks to Mac OS. Linux never sets this value in 
NVRAM, AFAIK, and Windows doesn't make this value available either.

On PowerMacs, this value already gets logged by the kernel. So I don't 
think any logging change is needed here.

-- 

      reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-21  1:51 Finn Thain
2019-06-24 19:57 ` Alexandre Belloni
2019-06-25  1:53   ` Finn Thain
2019-06-25  9:29     ` Alexandre Belloni
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 [this message]

Reply instructions:

You may reply publically 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=alpine.LNX.2.21.1907141013360.8@nippy.intranet \
    --to=fthain@telegraphics.com.au \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --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

Linux-RTC Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-rtc/0 linux-rtc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-rtc linux-rtc/ https://lore.kernel.org/linux-rtc \
		linux-rtc@vger.kernel.org linux-rtc@archiver.kernel.org
	public-inbox-index linux-rtc


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-rtc


AGPL code for this site: git clone https://public-inbox.org/ public-inbox