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
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
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
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,
>
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.
|
|
+ .
5 matches
Mail list logo