lkml.org 
[lkml]   [2019]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] rtc: Don't state that the RTC holds UTC in case it doesn't
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?

--

\
 
 \ /
  Last update: 2019-06-26 06:43    [W:0.101 / U:1.620 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site