<html><body><p><tt>hello Rick,</tt><br><br><tt>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.</tt><br><br><tt>I have put my comments inline.</tt><br><br><tt>Rick Altherr <raltherr@google.com> wrote on 07/08/2016 01:12:05 AM:<br><br>> From: Rick Altherr <raltherr@google.com></tt><br><tt>> To: Patrick Williams <patrick@stwcx.xyz></tt><br><tt>> Cc: Vishwanatha Subbanna/India/IBM@IBMIN, OpenBMC <openbmc@lists.ozlabs.org></tt><br><tt>> Date: 07/08/2016 01:12 AM</tt><br><tt>> Subject: Re: Issues with setting the timeofday</tt><br><tt>> <br>> In that case, I'd expect this behavior on the BMC assuming some form<br>> of NTP client has been started. The BMC's RTC (what hwclock is <br>> reading and writing) runs independent of the BMC's kernel clock <br>> (what date is reporting). The kernel (AFAIK) doesn't poll the RTC <br>> normally to keep in sync. Once the time is set at boot time, the <br>> kernel will just keep marching along based on the SoC's clock <br>> input. This can eventually lead to time skew between the kernel and<br>> RTC if they are using independent clocks (very very likely). <br>> Synchronization is left to userspace tools.</tt><br><tt>> <br>> root@barreleye:~# date -s '2016-12-25 12:34:56' ; hwclock -w<br>> Sun Dec 25 12:34:56 UTC 2016</tt><br><tt>> <br>> The first command sets the BMC kernel time to a known timestamp. <br>> The second writes that to the BMC's RTC.</tt><br><tt>> </tt><br><tt>> </tt><br><br><tt>Agreed. The intention was to write to the kernel time using settimeofday () and then push it onto BMC RTC.</tt><br><tt><br>> root@barreleye:~# date<br>> Thu Jul 7 13:07:37 UTC 2016</tt><br><tt>> <br>> Now you've read back the BMC kernel's time and it has been rewritten<br>> to current, real-world time. This only happens if some userspace <br>> process set the kernel's time independently. The BMC RTC is not <br>> involved here.</tt><br><tt>> </tt><br><tt>> </tt><br><br><tt>Correct. the kernel time was set by the user and this command was just to show that the </tt><br><tt>kernel time was getting overwritten. </tt><br><tt>I did not realize that systemd-timesyncd was running at the background. After killing the systemd-timesyncd, </tt><br><tt>I was seeing that settimeofday and gettimeofday was giving me what I wanted.</tt><br><tt><br>> root@barreleye:~# hwclock -r<br>> Sun Dec 25 12:35:01 2016 0.000000 seconds</tt><br><tt>> <br>> This reads back to the BMC RTC's time. It has advanced 5 seconds <br>> since it was written which seems plausible. Note this also strongly<br>> implies that the initial commands that set the kernel time and wrote<br>> it to the RTC were successful. It's also possible that the RTC just<br>> happened to be close to the desired time already but that seems veryunlikely.</tt><br><tt>> </tt><br><tt>></tt><br><br><tt>Yes.. That was my point. The kernel time was immediately getting overwritten.</tt><br><tt>Like I said, I was not aware that timesyncd was running.</tt><br><tt><br>> root@barreleye:~# hwclock -s</tt><br><tt>> <br>> This will read the BMC RTC's time and set the BMC kernel's time to <br>> that same time point. An immediate 'date' command _should_ return that time.</tt><br><tt>> </tt><br><tt>> <br>> root@barreleye:~# date<br>> Thu Jul 7 13:07:52 UTC 2016</tt><br><tt>> <br>> This is 15s after the last 'date' command. Given that this is the <br>> 3rd command to run since, there seems to be about 5s between <br>> commands on the CLI. That's plenty of time for ntpd or timesyncd to<br>> overwrite the kernel time with current NTP time.</tt><br><tt>> <br>> </tt><br><tt>> root@barreleye:~# </tt><br><tt>> <br>> On Thu, Jul 7, 2016 at 12:13 PM, Patrick Williams <patrick@stwcx.xyz> wrote:</tt><br><tt>> 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>> 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.</tt><br><tt>> <br>> > On Thu, Jul 7, 2016 at 11:23 AM, Patrick Williams <patrick@stwcx.xyz> 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 <br>> 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. <br>> 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 <br>> 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">https://github.com/openbmc/openbmc/issues/310</a><br>> > ><br>> > > > On Thu, Jul 7, 2016 at 6:06 AM, Vishwanatha Subbanna <<br>> > > vishwanath@in.ibm.com><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 haveany 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>> -------------------------------------------------------------------------------------<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: +91-80-46678255<br>> > > > > E-mail: vishwanath@in.ibm.com<br>> > > > ><br>> > > > ><br>> > > <br>> ----------------------------------------------------------------------------------<br>> > > > ><br>> > > > > _______________________________________________<br>> > > > > openbmc mailing list<br>> > > > > openbmc@lists.ozlabs.org<br>> > > > > <a href="https://lists.ozlabs.org/listinfo/openbmc">https://lists.ozlabs.org/listinfo/openbmc</a><br>> > > > ><br>> > > > ><br>> > ><br>> > > > _______________________________________________<br>> > > > openbmc mailing list<br>> > > > openbmc@lists.ozlabs.org<br>> > > > <a href="https://lists.ozlabs.org/listinfo/openbmc">https://lists.ozlabs.org/listinfo/openbmc</a><br>> > ><br>> > ><br>> > > --<br>> > > Patrick Williams<br>> > ><br></tt><br><tt>> --<br>> Patrick Williams</tt><BR>
</body></html>