All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Prarit Bhargava <prarit@redhat.com>
Cc: linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] time, Fix setting of hardware clock in NTP code
Date: Fri, 08 Feb 2013 15:50:54 -0800	[thread overview]
Message-ID: <51158F5E.9000007@linaro.org> (raw)
In-Reply-To: <51158DF2.3090702@redhat.com>

On 02/08/2013 03:44 PM, Prarit Bhargava wrote:
>
> On 02/08/2013 06:12 PM, John Stultz wrote:
>> On 02/08/2013 02:59 PM, Prarit Bhargava wrote:
>> Ok, I've got this queued in my tree. What sort of testing did you do with it?
>>
>> I want to make sure we don't run into any bad interactions with the existing
>> 15min cap on x86.
> John,
>
> I did the following:
>
> I used powerpc pseries systems and tested this using both positive and negative
> values of sys_tz.minuteswest, with both UTC and LOCAL in /etc/adjtime.  I dumped
> values of 'hwclock -D' and date and confirmed that I no longer see time
> increasing by sys_tz.minuteswest each reboot.
>
> I also tested x86 32-bit and 64-bit as a sanity check and verified that the
> current behaviour on those arches is the same; ie) I don't see *any* impact to
> the x86 rtc.  I dumped values of 'hwclock -D' and date, and again confirmed that
> I see no differences in values.  I did that with both UTC and LOCAL.
>
> I also tested a powerpc box and set the hwclock (via BIOS) back to Dec 6 2012 to
> see what would happen when I enabled ntp.  The system booted, set the system
> time to Dec 6 2012, and then properly ended up with both system time AND hwclock
> as Feb 8 2013 after systemd init .... (The *exact* time-of-day was correct as
> well.  I just can't remember the time I did it ;) )
>
> And I did the same thing (adjusting the BIOS date back) on x86. I only see the
> hours and minutes change, as we expect.  The year, month, day are unaffected
> with both UTC and LOCAL.
>
> tl;dr  Yup.  Tested as much as I could think of doing before submitting.  Tested
> on a both x86, powerpc.  Fixed the bug on powerpc.  No change in behavior seen
> with x86.
Great! This is perfect!

Thanks for being so thorough!
-john


      reply	other threads:[~2013-02-08 23:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-08 12:55 [PATCH] time, Fix setting of hardware clock in NTP code Prarit Bhargava
2013-02-08 21:46 ` John Stultz
2013-02-08 22:59   ` Prarit Bhargava
2013-02-08 23:12     ` John Stultz
2013-02-08 23:44       ` Prarit Bhargava
2013-02-08 23:50         ` John Stultz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51158F5E.9000007@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prarit@redhat.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.