On Fri, 22 Nov 2013 11:15:47 -0800
John Stultz wrote:
> On 11/22/2013 07:38 AM, Martin Schwidefsky wrote:
>
> > But that has the downside that it creates a negative ntp_error that
> > can only be corrected with an adjustment of tk->mult which takes a
> > long time.
>
> So the time it would
On Fri, 22 Nov 2013 11:15:47 -0800
John Stultz john.stu...@linaro.org wrote:
On 11/22/2013 07:38 AM, Martin Schwidefsky wrote:
But that has the downside that it creates a negative ntp_error that
can only be corrected with an adjustment of tk-mult which takes a
long time.
So the time
On 11/22/2013 07:38 AM, Martin Schwidefsky wrote:
> Greetings,
>
> I just hunted down a time related bug which caused the Linux internal
> xtime to drift away from the precise hardware clock provided by the
> TOD clock found in the s390 architecture.
>
> After a long search I came along this
Greetings,
I just hunted down a time related bug which caused the Linux internal
xtime to drift away from the precise hardware clock provided by the
TOD clock found in the s390 architecture.
After a long search I came along this lovely piece of code in
kernel/time/timekeeping.c:
#ifdef
Greetings,
I just hunted down a time related bug which caused the Linux internal
xtime to drift away from the precise hardware clock provided by the
TOD clock found in the s390 architecture.
After a long search I came along this lovely piece of code in
kernel/time/timekeeping.c:
#ifdef
On 11/22/2013 07:38 AM, Martin Schwidefsky wrote:
Greetings,
I just hunted down a time related bug which caused the Linux internal
xtime to drift away from the precise hardware clock provided by the
TOD clock found in the s390 architecture.
After a long search I came along this lovely piece
6 matches
Mail list logo
