Issues with setting the timeofday

Fri Jul 8 05:42:05 AEST 2016

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.

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

>
> 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 very unlikely.

>
> 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 have any
> 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/20160707/e544ffae/attachment-0001.html>