Re: [PATCH] time, Fix setting of hardware clock in NTP code

2013-02-08 Thread John Stultz
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 15

Re: [PATCH] time, Fix setting of hardware clock in NTP code

2013-02-08 Thread Prarit Bhargava
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 f

Re: [PATCH] time, Fix setting of hardware clock in NTP code

2013-02-08 Thread Prarit Bhargava
At init time, if the system time is "warped" forward in warp_clock() it will differ from the hardware clock by sys_tz.tz_minuteswest. This time difference is not taken into account when ntp updates the hardware clock, and this causes the system time to jump forward by this offset every reboot. Th

Re: [PATCH] time, Fix setting of hardware clock in NTP code

2013-02-08 Thread John Stultz
On 02/08/2013 02:59 PM, Prarit Bhargava wrote: At init time, if the system time is "warped" forward in warp_clock() it will differ from the hardware clock by sys_tz.tz_minuteswest. This time difference is not taken into account when ntp updates the hardware clock, and this causes the system time

Re: [PATCH] time, Fix setting of hardware clock in NTP code

2013-02-08 Thread John Stultz
On Fri, Feb 8, 2013 at 4:55 AM, Prarit Bhargava wrote: > diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c > index 24174b4..e98f6b7 100644 > --- a/kernel/time/ntp.c > +++ b/kernel/time/ntp.c > @@ -510,8 +510,12 @@ static void sync_cmos_clock(struct work_struct *work) > } > > getns

[PATCH] time, Fix setting of hardware clock in NTP code

2013-02-08 Thread Prarit Bhargava
At init time, if the system time is "warped" forward in warp_clock() it will differ from the hardware clock by sys_tz.tz_minuteswest. This time difference is not taken into account when ntp updates the hardware clock, and this causes the system time to jump forward by this offset every reboot. Th

Re: [RFE PATCH] time, Fix setting of hardware clock in NTP code

2013-02-07 Thread Prarit Bhargava
On 02/07/2013 02:52 PM, John Stultz wrote: > On 02/07/2013 10:20 AM, Prarit Bhargava wrote: >> >> On 02/07/2013 12:24 PM, John Stultz wrote: >>> On Thu, Feb 7, 2013 at 5:29 AM, Prarit Bhargava wrote: >>> >> I'm not sure I understand the purpose behind the +/-15 minute window? Is it >> just to p

Re: [RFE PATCH] time, Fix setting of hardware clock in NTP code

2013-02-07 Thread John Stultz
On 02/07/2013 10:20 AM, Prarit Bhargava wrote: On 02/07/2013 12:24 PM, John Stultz wrote: On Thu, Feb 7, 2013 at 5:29 AM, Prarit Bhargava wrote: We do not see this manifest on some architectures because they limit changes to the rtc to +/-15 minutes of the current value of the rtc (x86, alpha

Re: [RFE PATCH] time, Fix setting of hardware clock in NTP code

2013-02-07 Thread Prarit Bhargava
On 02/07/2013 12:24 PM, John Stultz wrote: > On Thu, Feb 7, 2013 at 5:29 AM, Prarit Bhargava wrote: >> We do not see this manifest on some architectures because they limit changes >> to the rtc to +/-15 minutes of the current value of the rtc (x86, alpha, >> mn10300). Other arches do nothing (c

Re: [RFE PATCH] time, Fix setting of hardware clock in NTP code

2013-02-07 Thread John Stultz
On Thu, Feb 7, 2013 at 5:29 AM, Prarit Bhargava wrote: > The problem with this model is what happens if /etc/adjtime is LOCAL, ie) > the rtc is set to localtime: > > Reboot the system, on the next boot, > rtc0_time = rtc + sys_tz.tz_minuteswest > Reboot the system, on the next boot, >

[RFE PATCH] time, Fix setting of hardware clock in NTP code

2013-02-07 Thread Prarit Bhargava
I have found a long existing bug in the ntp code that causes a forwarding of time equal to that of the local timezone every reboot. This is the sequence indicating what happens during boot. + start boot | + rtc read, written as UTC into xtime/system clock. This time is rtc0_time below. | | + .