Issues with setting the timeofday

Fri Jul 8 20:15:18 AEST 2016

hello Rick,

As Patrick mentioned, the intention was to set the time of day using
settimeofday() and then read it back as a verification process and that was
not giving us expected results.

I have put my comments inline.

Rick Altherr <raltherr at google.com> wrote on 07/08/2016 01:12:05 AM:

> From: Rick Altherr <raltherr at google.com>
> To: Patrick Williams <patrick at stwcx.xyz>
> Cc: Vishwanatha Subbanna/India/IBM at IBMIN, OpenBMC
<openbmc at lists.ozlabs.org>
> Date: 07/08/2016 01:12 AM
> Subject: Re: Issues with setting the timeofday
>
> In that case, I'd expect this behavior on the BMC assuming some form
> of NTP client has been started.  The BMC's RTC (what hwclock is
> reading and writing) runs independent of the BMC's kernel clock
> (what date is reporting).  The kernel (AFAIK) doesn't poll the RTC
> normally to keep in sync.  Once the time is set at boot time, the
> kernel will just keep marching along based on the SoC's clock
> input.  This can eventually lead to time skew between the kernel and
> RTC if they are using independent clocks (very very likely).
> Synchronization is left to userspace tools.
>
> root at barreleye:~# date -s '2016-12-25 12:34:56' ; hwclock -w
> Sun Dec 25 12:34:56 UTC 2016
>
> The first command sets the BMC kernel time to a known timestamp.
> The second writes that to the BMC's RTC.
>
>

Agreed. The intention was to write to the kernel time using settimeofday ()
and then push it onto BMC RTC.

> root at barreleye:~# date
> Thu Jul 7 13:07:37 UTC 2016
>
> Now you've read back the BMC kernel's time and it has been rewritten
> to current, real-world time.  This only happens if some userspace
> process set the kernel's time independently.  The BMC RTC is not
> involved here.
>
>

Correct. the kernel time was set by the user and this command was just to
show that the
kernel time was getting overwritten.
I did not realize that systemd-timesyncd was running at the background.
After killing the systemd-timesyncd,
I was seeing that settimeofday and gettimeofday was giving me what I
wanted.

> root at barreleye:~# hwclock -r
> Sun Dec 25 12:35:01 2016 0.000000 seconds
>
> This reads back to the BMC RTC's time.  It has advanced 5 seconds
> since it was written which seems plausible.  Note this also strongly
> implies that the initial commands that set the kernel time and wrote
> it to the RTC were successful.  It's also possible that the RTC just
> happened to be close to the desired time already but that seems
veryunlikely.
>
>

Yes.. That was my point. The kernel time was immediately getting
overwritten.
Like I said, I was not aware that timesyncd was running.

> root at barreleye:~# hwclock -s
>
> This will read the BMC RTC's time and set the BMC kernel's time to
> that same time point.  An immediate 'date' command _should_ return that
time.
>
>
> root at barreleye:~# date
> Thu Jul 7 13:07:52 UTC 2016
>
> This is 15s after the last 'date' command.  Given that this is the
> 3rd command to run since, there seems to be about 5s between
> commands on the CLI.  That's plenty of time for ntpd or timesyncd to
> overwrite the kernel time with current NTP time.
>
>
> root at barreleye:~#
>
> On Thu, Jul 7, 2016 at 12:13 PM, Patrick Williams <patrick at stwcx.xyz>
wrote:
> On Thu, Jul 07, 2016 at 11:32:51AM -0700, Rick Altherr wrote:
> > I'm unfamiliar with Barreleye.  Does the host use the BMC as an RTC?
Are
> > the commands in the first post being run on the host or on the BMC?
>
> Rick, good questions.
>
> On all the current Power systems, the Host does not have its own RTC.
The
> skiboot code will create an RTC for the kernel by using IPMI commands
down
> to the BMC.  They use the standard get-sel-time / set-sel-time IPMI
> command for this.  Other-BMC systems already operated this way, and since
> the Host firmware support was already there for other-BMC systems, we
> implemented this same behavior on openBMC.  There are also other IPMI
> commands that we implemented to emulate other-BMC behavior so as to not
> require Host firmware changes for openBMC.
>
> The commands Vishwa has below here are ran from the BMC.  The commands
> in the Github issue are also ran from the BMC, but you will see a call
> to '/tmp/ipmitool' there.  That is a development version of the ipmitool
> that will call into the dbus stack as if the Host sent an IPMI message
> through the BT interface.  Thus, 'ipmitool -l dbus sel time set ...' and
> 'ipmitool -l dbus sel time get' are emulating the behavior of the host,
> while 'date' is interacting with the BMC's kernel time subsystem.
>
> > On Thu, Jul 7, 2016 at 11:23 AM, Patrick Williams <patrick at stwcx.xyz>
wrote:
> >
> > > On Thu, Jul 07, 2016 at 09:52:36AM -0700, Rick Altherr wrote:
> > > > If ntpd or systemd-timesyncd is running, this makes perfect
> sense.  Linux
> > > > maintains current time in the kernel.  The hardware RTC is only
used to
> > > > load an initial time at boot and is written during shutdown.
> When an NTP
> > > > daemon is running and an NTP server is reachable, it will adjust
the
> > > > kernel's current time to match NTP time.  I believe with timesyncd,
it
> > > > simply steps time instead of slewing like ntpd does.
> > > >
> > > > What are you trying to accomplish?  There is likely a way to
> do it if you
> > > > can describe what you want to have happen.
> > >
> > > It looks like maybe this is related to Github issue
openbmc/openbmc#310.
> > >
> > >     https://github.com/openbmc/openbmc/issues/310
> > >
> > > > On Thu, Jul 7, 2016 at 6:06 AM, Vishwanatha Subbanna <
> > > vishwanath at in.ibm.com>
> > > > wrote:
> > > >
> > > > > hey Joel,
> > > > >
> > > > > Here is what I am seeing on one the Barreleye box that is running
> > > > > "4.4.12-openbmc-20160606-1 : kernel". I can see that time gets
set but
> > > > > reverts immediately. Syncing what's in hwclock does not haveany
effect
> > > > > too. Any thoughts ?
> > > > >
> > > > > root at barreleye:~# date -s '2016-12-25 12:34:56' ; hwclock -w
> > > > > Sun Dec 25 12:34:56 UTC 2016
> > > > >
> > > > > root at barreleye:~# date
> > > > > Thu Jul 7 13:07:37 UTC 2016
> > > > >
> > > > > root at barreleye:~# hwclock -r
> > > > > Sun Dec 25 12:35:01 2016 0.000000 seconds
> > > > >
> > > > > root at barreleye:~# hwclock -s
> > > > >
> > > > > root at barreleye:~# date
> > > > > Thu Jul 7 13:07:52 UTC 2016
> > > > > root at barreleye:~#
> > > > >
> > > > > Thanks
> > > > >
> > > > >
> > > > >
> > >
>
-------------------------------------------------------------------------------------

> > > > > Thanks and Regards,
> > > > > Vishwanath.
> > > > > Advisory Software Engineer,
> > > > > Power Firmware Development,
> > > > > Systems &Technology Lab,
> > > > > MG2-6F-255 , Manyata Embassy Business Park,
> > > > > Bangalore , KA , 560045
> > > > > Ph: +91-80-46678255
> > > > > E-mail: vishwanath at in.ibm.com
> > > > >
> > > > >
> > >
>
----------------------------------------------------------------------------------

> > > > >
> > > > > _______________________________________________
> > > > > openbmc mailing list
> > > > > openbmc at lists.ozlabs.org
> > > > > https://lists.ozlabs.org/listinfo/openbmc
> > > > >
> > > > >
> > >
> > > > _______________________________________________
> > > > openbmc mailing list
> > > > openbmc at lists.ozlabs.org
> > > > https://lists.ozlabs.org/listinfo/openbmc
> > >
> > >
> > > --
> > > Patrick Williams
> > >

> --
> Patrick Williams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160708/f971a434/attachment-0001.html>