[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.21.1906251043050.8@nippy.intranet>
Date: Tue, 25 Jun 2019 11:53:49 +1000 (AEST)
From: Finn Thain <fthain@...egraphics.com.au>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>
cc: Alessandro Zummo <a.zummo@...ertech.it>, userm57@...oo.com,
linux-rtc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rtc: Don't state that the RTC holds UTC in case it
doesn't
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?
--
> > Signed-off-by: Finn Thain <fthain@...egraphics.com.au>
> > ---
> > drivers/rtc/hctosys.c | 2 +-
> > tools/power/pm-graph/bootgraph.py | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
> > index ff2092a0d38c..2270eca23203 100644
> > --- a/drivers/rtc/hctosys.c
> > +++ b/drivers/rtc/hctosys.c
> > @@ -58,7 +58,7 @@ static int __init rtc_hctosys(void)
> >
> > err = do_settimeofday64(&tv64);
> >
> > - dev_info(rtc->dev.parent, "setting system clock to %ptR UTC (%lld)\n",
> > + dev_info(rtc->dev.parent, "setting system clock to %ptR (%lld)\n",
> > &tm, (long long)tv64.tv_sec);
> >
> > err_read:
> > diff --git a/tools/power/pm-graph/bootgraph.py b/tools/power/pm-graph/bootgraph.py
> > index 6dae57041537..5a045d1cb879 100755
> > --- a/tools/power/pm-graph/bootgraph.py
> > +++ b/tools/power/pm-graph/bootgraph.py
> > @@ -333,7 +333,7 @@ def parseKernelLog():
> > if(not sysvals.stamp['kernel']):
> > sysvals.stamp['kernel'] = sysvals.kernelVersion(msg)
> > continue
> > - m = re.match('.* setting system clock to (?P<t>.*) UTC.*', msg)
> > + m = re.match('.* setting system clock to (?P<t>.*) (?:UTC )?\(.*', msg)
> > if(m):
> > bt = datetime.strptime(m.group('t'), '%Y-%m-%d %H:%M:%S')
> > bt = bt - timedelta(seconds=int(ktime))
> > --
> > 2.21.0
> >
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
Powered by blists - more mailing lists