Re: [Xenomai-help] Xenomai 2.5-rc2 clock_gettime bad tv_nsec value

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Steve wrote:
> On 07/08/2009, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
>> Steve wrote:
>>> Hi,
>>>
>>> Using Xenomai 2.5-rc2 on Linux 2.6.29.4 the following code
>>> periodically produces a bad result:
>>>
>>> clock_gettime(CLOCK_REALTIME, timespec);
>>>
>>> Where it assigns a timespec.tv_nsec that is greater than 1000 million.
>>>  If it helps the maximum returned value that i have seen before tv_sec
>>> increments and tv_nsec returns to a 'safe' value is 1048044075.
>>>
>>> This does not happen using Xenomai 2.4.8 on the same Linux kernel.
>>> There are some differences between the kernel config files used for my
>>> 2.4.8 setup and 2.5-rc2 setup, but I don't imagine that that is the
>>> problem.
>>>
>>> Any thoughts?
>> Well, yes. Xenomai 2.5-rc2 has been modified to do the conversion
>> between ticks and timespec without divisions. I am afraid in some cases
>> we are wrong (essentially, we replace the division with a
>> multiplication, but it is entirely possible that the result of the
>> multiplication is off by one, and so when computing the remainder, we
>> get a too large value). Could you apply the following patch? It will
>> modify clock_gettime implementation in kernel-space to print the value
>> before conversion when the bug happens. Also tell us if you are running
>> in periodic mode or aperiodic mode (if you do not know, then you are
>> running in aperiodic mode).
>>
>> diff --git a/ksrc/skins/posix/clock.c b/ksrc/skins/posix/clock.c
>> index 553e123..63a42fa 100644
>> --- a/ksrc/skins/posix/clock.c
>> +++ b/ksrc/skins/posix/clock.c
>> @@ -117,7 +117,10 @@ int clock_gettime(clockid_t clock_id, struct timespec
>> *tp)
>>
>>         switch (clock_id) {
>>         case CLOCK_REALTIME:
>> -               ticks2ts(tp, xntbase_get_time(pse51_tbase));
>> +               cpu_time = xntbase_get_time(pse51_tbase);
>> +               ticks2ts(tp, cpu_time);
>> +               if (tp->tv_nsec > 1000000000)
>> +                       printk("Bad conversion, time: %llu\n", cpu_time);
>>                 break;
>>
>>         case CLOCK_MONOTONIC:
>>
>>
>> --
>> 					    Gilles.
>>
> 
> Hi Gilles,
> 
> Sorry for the extreme delay, various other priorities got in the way.
> 
> Once the patch is applied and a test program is run dmesg has lots of
> 'Bad conversion's which are all very similar.  Here are the final 10:
> 
> [  192.038848] Bad conversion, time: 1250669597038861231
> [  192.039851] Bad conversion, time: 1250669597039861940
> [  192.040851] Bad conversion, time: 1250669597040863024
> [  192.041848] Bad conversion, time: 1250669597041861613
> [  192.042849] Bad conversion, time: 1250669597042862242
> [  192.043850] Bad conversion, time: 1250669597043861252
> [  192.044850] Bad conversion, time: 1250669597044862442
> [  192.045848] Bad conversion, time: 1250669597045861823
> [  192.046848] Bad conversion, time: 1250669597046861573
> [  192.047850] Bad conversion, time: 1250669597047861421
> 
> I can add the following code to my program to deal with this problem;
> would it be sensible to write something similar at a lower level to
> fix the problem, or has this been avoided due to issues with while
> loops (speed or determinism)?
> 
> while (tp->tv_nsec > NANOSEC_PER_SEC)
> {
>    tp->tv_nsec = tp->tv_nsec - NANOSEC_PER_SEC
>    tp->tv_sec = tp->tv_sec + 1;
> }

I hope to avoid this. Could you tell us on what platform you get this
behaviour?

-- 
                                          Gilles