lkml.org 
[lkml]   [2019]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [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@telegraphics.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
>

\
 
 \ /
  Last update: 2019-06-25 03:54    [W:0.076 / U:7.436 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site