* timekeeping_adjust may set mult to 0
@ 2013-02-11 15:48 David Engraf
2013-02-15 22:34 ` John Stultz
0 siblings, 1 reply; 3+ messages in thread
From: David Engraf @ 2013-02-11 15:48 UTC (permalink / raw)
To: John Stultz, Thomas Gleixner; +Cc: linux-kernel
Hi,
I have encountered a problem when a linux system uses a clocksource with
mult = 1 and shift = 0 (clocksource cycle = nanoseconds). It may happen
that the function timekeeping_adjust reduces the value of mult to 0 when
error is lower than the interval [1].
As soon as timekeeper.mult is 0, ktime_get will no longer work because
it uses timekeeping_get_ns which converts the cycle to nanoseconds with
mult as 0 and the system clocksource returns always 0.
Best regards
David Engraf
[1] http://lxr.linux.no/linux+v3.0.62/kernel/time/timekeeping.c#L821
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: timekeeping_adjust may set mult to 0
2013-02-11 15:48 timekeeping_adjust may set mult to 0 David Engraf
@ 2013-02-15 22:34 ` John Stultz
2013-02-26 13:05 ` David Engraf
0 siblings, 1 reply; 3+ messages in thread
From: John Stultz @ 2013-02-15 22:34 UTC (permalink / raw)
To: David Engraf; +Cc: John Stultz, Thomas Gleixner, linux-kernel
On Mon, Feb 11, 2013 at 7:48 AM, David Engraf <david.engraf@sysgo.com> wrote:
> I have encountered a problem when a linux system uses a clocksource with
> mult = 1 and shift = 0 (clocksource cycle = nanoseconds). It may happen that
> the function timekeeping_adjust reduces the value of mult to 0 when error is
> lower than the interval [1].
> As soon as timekeeper.mult is 0, ktime_get will no longer work because it
> uses timekeeping_get_ns which converts the cycle to nanoseconds with mult as
> 0 and the system clocksource returns always 0.
So you *don't* want to use shift=0, since that kills the ability for
the frequency adjustment code to do anything, as you've found.
Instead of calculating the clocksource mult/shift pair yourself,
please use clocksource_register_hz/khz().
I'm hoping to kill off the open clocksource_register() call soon, to
avoid this sort of confusion. Sorry for the trouble.
thanks
-john
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: timekeeping_adjust may set mult to 0
2013-02-15 22:34 ` John Stultz
@ 2013-02-26 13:05 ` David Engraf
0 siblings, 0 replies; 3+ messages in thread
From: David Engraf @ 2013-02-26 13:05 UTC (permalink / raw)
To: John Stultz; +Cc: John Stultz, Thomas Gleixner, linux-kernel
Am 15.02.2013 23:34, schrieb John Stultz:
> On Mon, Feb 11, 2013 at 7:48 AM, David Engraf <david.engraf@sysgo.com> wrote:
>> I have encountered a problem when a linux system uses a clocksource with
>> mult = 1 and shift = 0 (clocksource cycle = nanoseconds). It may happen that
>> the function timekeeping_adjust reduces the value of mult to 0 when error is
>> lower than the interval [1].
>> As soon as timekeeper.mult is 0, ktime_get will no longer work because it
>> uses timekeeping_get_ns which converts the cycle to nanoseconds with mult as
>> 0 and the system clocksource returns always 0.
>
> So you *don't* want to use shift=0, since that kills the ability for
> the frequency adjustment code to do anything, as you've found.
The problem is not shift=0 it's mult=1. The frequency adjustment code
may increase/decrease mult and mult=0 will not work.
> Instead of calculating the clocksource mult/shift pair yourself,
> please use clocksource_register_hz/khz().
Thanks, I will try it.
Best regards
- David
> I'm hoping to kill off the open clocksource_register() call soon, to
> avoid this sort of confusion. Sorry for the trouble.
>
> thanks
> -john
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-02-26 13:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-11 15:48 timekeeping_adjust may set mult to 0 David Engraf
2013-02-15 22:34 ` John Stultz
2013-02-26 13:05 ` David Engraf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).