On Fri, Feb 20, 2015 at 09:15:23AM -0500, Prarit Bhargava wrote:
> On 02/19/2015 12:00 PM, Jiri Bohac wrote:
> > Prarit, can you explain who sets the STA_PLL flag, so that
> > process_adj_status() detects a STA_PLL->!STA_PLL transition and
> > goes to the branch that sets time_state = TIME_OK?
>
>
On 02/19/2015 12:00 PM, Jiri Bohac wrote:
> Hi,
>
> I'm trying to understand what exactly is going on here...
>
> On Thu, Feb 12, 2015 at 08:58:19AM -0500, Prarit Bhargava wrote:
>> The test did the following in userspace:
>>
>> tx.modes = ADJ_STATUS;
>> tx.status = STA_INS;
>>
On 02/17/2015 06:16 PM, John Stultz wrote:
> On Thu, Feb 12, 2015 at 5:58 AM, Prarit Bhargava wrote:
>>
>> which was intended to mimic the insertion of a leap second. A
>> successful run of the test would result in the time_state transitioning
>> from TIME_OK to TIME_INS, then to TIME_OOP when
Hi,
I'm trying to understand what exactly is going on here...
On Thu, Feb 12, 2015 at 08:58:19AM -0500, Prarit Bhargava wrote:
> The test did the following in userspace:
>
> tx.modes = ADJ_STATUS;
> tx.status = STA_INS;
>
> /* send leap second request */
> ret = ad
On Wed, Feb 18, 2015 at 06:14:04PM +0100, Jiri Bohac wrote:
> I think the only real problem occurs when the adjtimex is called in the
> the TIME_OOP state
... or the TIME_WAIT state ...
> with STA_PLL cleared _and_ STA_INS set.
> In this case the state machine is reset to TIME_OK but goes back
On Tue, Feb 17, 2015 at 03:16:18PM -0800, John Stultz wrote:
> Ok, thanks for the more verbose explanation. Although this is more a
> history of what you've seen rather then the crux of the change.
>
> To distill this down just a bit, the point is the usual mode for NTP
> time_state machine looks
On Thu, Feb 12, 2015 at 5:58 AM, Prarit Bhargava wrote:
> During leap second insertion testing it was noticed that a small window
> exists where the time_state could be reset such that
> time_state = TIME_OK, which then causes the leap second to not occur, or
> causes the entire leap second state
During leap second insertion testing it was noticed that a small window
exists where the time_state could be reset such that
time_state = TIME_OK, which then causes the leap second to not occur, or
causes the entire leap second state machine to fail with time_state =
TIME_INS at the end of the leap
On 02/10/2015 06:47 PM, John Stultz wrote:
> On Sun, Feb 8, 2015 at 2:29 AM, Prarit Bhargava wrote:
>> During leap second insertion testing it was noticed that a small window
>> exists where the time_state could be reset such that
>> time_state = TIME_OK, which then causes the leap second to not
On Sun, Feb 8, 2015 at 2:29 AM, Prarit Bhargava wrote:
> During leap second insertion testing it was noticed that a small window
> exists where the time_state could be reset such that
> time_state = TIME_OK, which then causes the leap second to not occur, or
> causes the entire leap second state m
On Sat, Feb 07, 2015 at 01:29:39PM -0500, Prarit Bhargava wrote:
> During leap second insertion testing it was noticed that a small window
> exists where the time_state could be reset such that
> time_state = TIME_OK, which then causes the leap second to not occur, or
> causes the entire leap secon
During leap second insertion testing it was noticed that a small window
exists where the time_state could be reset such that
time_state = TIME_OK, which then causes the leap second to not occur, or
causes the entire leap second state machine to fail.
While this is highly unlikely to ever happen in
Resending ...
P.
8<
During leap second insertion testing it was noticed that a small window
exists where the time_state could be reset such that
time_state = TIME_OK, which then causes the leap second to not occur, or
causes the entire leap second state machine to fail.
While this is hi
During leap second insertion testing it was noticed that a small window
exists where the time_state could be reset such that
time_state = TIME_OK, which then causes the leap second to not occur, or
causes the entire leap second state machine to fail.
While this is highly unlikely to ever happen in
14 matches
Mail list logo