Re: [PATCH] rtc: Don't state that the RTC holds UTC in case it doesn't
From: Finn Thain
Date: Wed Jun 26 2019 - 00:42:39 EST
On Tue, 25 Jun 2019, Alexandre Belloni wrote:
> 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?
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
# hwclock --show
# date --iso-8601=s
As expected, the kernel message still agrees with the output from hwclock.
> 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.
> 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?