Re: [PATCH] rtc: Don't state that the RTC holds UTC in case it doesn't

[Finn Thain <fthain@telegraphics.com.au>]

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
/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.

> 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?

--