<div dir="ltr">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.<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">root@barreleye:~# date -s '</span><span class="gmail-aBn" tabindex="0" style="font-size:12.8px"><span class="gmail-aQJ">2016-12-25 12:34:56</span></span><span style="font-size:12.8px">' ; hwclock -w<br></span><span style="font-size:12.8px">Sun Dec 25 12:34:56 UTC 2016</span></blockquote><div><br></div><div>The first command sets the BMC kernel time to a known timestamp.  The second writes that to the BMC's RTC.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px"><br></span><span style="font-size:12.8px">root@barreleye:~# date<br></span><span style="font-size:12.8px">Thu Jul 7 13:07:37 UTC 2016</span></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px"><br></span><span style="font-size:12.8px">root@barreleye:~# hwclock -r<br></span><span class="gmail-aBn" tabindex="0" style="font-size:12.8px"><span class="gmail-aQJ">Sun Dec 25 12:35:01 2016</span></span><span style="font-size:12.8px"> 0.000000 seconds</span></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px"><br></span><span style="font-size:12.8px">root@barreleye:~# hwclock -s</span></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px"><br></span><span style="font-size:12.8px">root@barreleye:~# date<br></span><span style="font-size:12.8px">Thu Jul 7 13:07:52 UTC 2016<br></span></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px"></span><span style="font-size:12.8px">root@barreleye:~# </span></blockquote></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 12:13 PM, Patrick Williams <span dir="ltr"><<a href="mailto:patrick@stwcx.xyz" target="_blank">patrick@stwcx.xyz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Jul 07, 2016 at 11:32:51AM -0700, Rick Altherr wrote:<br>
> I'm unfamiliar with Barreleye.  Does the host use the BMC as an RTC?  Are<br>
> the commands in the first post being run on the host or on the BMC?<br>
<br>
</span>Rick, good questions.<br>
<br>
On all the current Power systems, the Host does not have its own RTC.  The<br>
skiboot code will create an RTC for the kernel by using IPMI commands down<br>
to the BMC.  They use the standard get-sel-time / set-sel-time IPMI<br>
command for this.  Other-BMC systems already operated this way, and since<br>
the Host firmware support was already there for other-BMC systems, we<br>
implemented this same behavior on openBMC.  There are also other IPMI<br>
commands that we implemented to emulate other-BMC behavior so as to not<br>
require Host firmware changes for openBMC.<br>
<br>
The commands Vishwa has below here are ran from the BMC.  The commands<br>
in the Github issue are also ran from the BMC, but you will see a call<br>
to '/tmp/ipmitool' there.  That is a development version of the ipmitool<br>
that will call into the dbus stack as if the Host sent an IPMI message<br>
through the BT interface.  Thus, 'ipmitool -l dbus sel time set ...' and<br>
'ipmitool -l dbus sel time get' are emulating the behavior of the host,<br>
while 'date' is interacting with the BMC's kernel time subsystem.<br>
<div class="HOEnZb"><div class="h5"><br>
> On Thu, Jul 7, 2016 at 11:23 AM, Patrick Williams <<a href="mailto:patrick@stwcx.xyz">patrick@stwcx.xyz</a>> wrote:<br>
><br>
> > On Thu, Jul 07, 2016 at 09:52:36AM -0700, Rick Altherr wrote:<br>
> > > If ntpd or systemd-timesyncd is running, this makes perfect sense.  Linux<br>
> > > maintains current time in the kernel.  The hardware RTC is only used to<br>
> > > load an initial time at boot and is written during shutdown.  When an NTP<br>
> > > daemon is running and an NTP server is reachable, it will adjust the<br>
> > > kernel's current time to match NTP time.  I believe with timesyncd, it<br>
> > > simply steps time instead of slewing like ntpd does.<br>
> > ><br>
> > > What are you trying to accomplish?  There is likely a way to do it if you<br>
> > > can describe what you want to have happen.<br>
> ><br>
> > It looks like maybe this is related to Github issue openbmc/openbmc#310.<br>
> ><br>
> >     <a href="https://github.com/openbmc/openbmc/issues/310" rel="noreferrer" target="_blank">https://github.com/openbmc/openbmc/issues/310</a><br>
> ><br>
> > > On Thu, Jul 7, 2016 at 6:06 AM, Vishwanatha Subbanna <<br>
> > <a href="mailto:vishwanath@in.ibm.com">vishwanath@in.ibm.com</a>><br>
> > > wrote:<br>
> > ><br>
> > > > hey Joel,<br>
> > > ><br>
> > > > Here is what I am seeing on one the Barreleye box that is running<br>
> > > > "4.4.12-openbmc-20160606-1 : kernel". I can see that time gets set but<br>
> > > > reverts immediately. Syncing what's in hwclock does not have any effect<br>
> > > > too. Any thoughts ?<br>
> > > ><br>
> > > > root@barreleye:~# date -s '2016-12-25 12:34:56' ; hwclock -w<br>
> > > > Sun Dec 25 12:34:56 UTC 2016<br>
> > > ><br>
> > > > root@barreleye:~# date<br>
> > > > Thu Jul 7 13:07:37 UTC 2016<br>
> > > ><br>
> > > > root@barreleye:~# hwclock -r<br>
> > > > Sun Dec 25 12:35:01 2016 0.000000 seconds<br>
> > > ><br>
> > > > root@barreleye:~# hwclock -s<br>
> > > ><br>
> > > > root@barreleye:~# date<br>
> > > > Thu Jul 7 13:07:52 UTC 2016<br>
> > > > root@barreleye:~#<br>
> > > ><br>
> > > > Thanks<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > -------------------------------------------------------------------------------------<br>
> > > > Thanks and Regards,<br>
> > > > Vishwanath.<br>
> > > > Advisory Software Engineer,<br>
> > > > Power Firmware Development,<br>
> > > > Systems &Technology Lab,<br>
> > > > MG2-6F-255 , Manyata Embassy Business Park,<br>
> > > > Bangalore , KA , 560045<br>
> > > > Ph: <a href="tel:%2B91-80-46678255" value="+918046678255">+91-80-46678255</a><br>
> > > > E-mail: <a href="mailto:vishwanath@in.ibm.com">vishwanath@in.ibm.com</a><br>
> > > ><br>
> > > ><br>
> > ----------------------------------------------------------------------------------<br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > openbmc mailing list<br>
> > > > <a href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a><br>
> > > > <a href="https://lists.ozlabs.org/listinfo/openbmc" rel="noreferrer" target="_blank">https://lists.ozlabs.org/listinfo/openbmc</a><br>
> > > ><br>
> > > ><br>
> ><br>
> > > _______________________________________________<br>
> > > openbmc mailing list<br>
> > > <a href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a><br>
> > > <a href="https://lists.ozlabs.org/listinfo/openbmc" rel="noreferrer" target="_blank">https://lists.ozlabs.org/listinfo/openbmc</a><br>
> ><br>
> ><br>
> > --<br>
> > Patrick Williams<br>
> ><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Patrick Williams<br>
</font></span></blockquote></div><br></div>