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

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

[Steve]

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?

Steve

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

[Gilles Chanteperdrix]

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.

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

[Steve]

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 this helps,

Steve

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

[Gilles Chanteperdrix]

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

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

[Steve]

On 19/08/2009, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
> 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
>
>

Were you going to delay handling this until later, or were you hoping
it wouldn't be a problem?  If it's the former then this is not my
number one priority at the moment, so from my perspective I can wait
until the next release candidate / release.

Linux kernel: 2.6.29.4
Xenomai: 2.5-rc2
Adeos: adeos-ipipe-2.6.29.4-x86-2.4-01

OS: Ubuntu (8.04 with updates)
Hardware:
Intel Core 2 CPU, kernel compiled using processor family 'Pentium-4/etc'

Steve

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

[Gilles Chanteperdrix]

Steve wrote:
> Were you going to delay handling this until later, or were you hoping
> it wouldn't be a problem?  If it's the former then this is not my
> number one priority at the moment, so from my perspective I can wait
> until the next release candidate / release.

To be completely frank, I was not really worried about this issue, since
you had not answered, I thought that maybe the issue was in your test
program.

> 
> Linux kernel: 2.6.29.4
> Xenomai: 2.5-rc2
> Adeos: adeos-ipipe-2.6.29.4-x86-2.4-01
> 
> OS: Ubuntu (8.04 with updates)
> Hardware:
> Intel Core 2 CPU, kernel compiled using processor family 'Pentium-4/etc'

compiled for 32 or 64 bits?

-- 
                                          Gilles

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

[Steve]

On 19/08/2009, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
> Steve wrote:
>> Were you going to delay handling this until later, or were you hoping
>> it wouldn't be a problem?  If it's the former then this is not my
>> number one priority at the moment, so from my perspective I can wait
>> until the next release candidate / release.
>
> To be completely frank, I was not really worried about this issue, since
> you had not answered, I thought that maybe the issue was in your test
> program.
>
>>
>> Linux kernel: 2.6.29.4
>> Xenomai: 2.5-rc2
>> Adeos: adeos-ipipe-2.6.29.4-x86-2.4-01
>>
>> OS: Ubuntu (8.04 with updates)
>> Hardware:
>> Intel Core 2 CPU, kernel compiled using processor family 'Pentium-4/etc'
>
> compiled for 32 or 64 bits?
>
> --
>                                           Gilles
>
>

32 bit,

Steve

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

[Gilles Chanteperdrix]

Steve wrote:
> On 19/08/2009, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
>> Steve wrote:
>>> Were you going to delay handling this until later, or were you hoping
>>> it wouldn't be a problem?  If it's the former then this is not my
>>> number one priority at the moment, so from my perspective I can wait
>>> until the next release candidate / release.
>> To be completely frank, I was not really worried about this issue, since
>> you had not answered, I thought that maybe the issue was in your test
>> program.
>>
>>> Linux kernel: 2.6.29.4
>>> Xenomai: 2.5-rc2
>>> Adeos: adeos-ipipe-2.6.29.4-x86-2.4-01
>>>
>>> OS: Ubuntu (8.04 with updates)
>>> Hardware:
>>> Intel Core 2 CPU, kernel compiled using processor family 'Pentium-4/etc'
>> compiled for 32 or 64 bits?
>>
>> --
>>                                           Gilles
>>
>>
> 
> 32 bit,

Ok. I will work on this tonight.

-- 
                                          Gilles

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

[Gilles Chanteperdrix]

Steve wrote:
> On 19/08/2009, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
>> Steve wrote:
>>> Were you going to delay handling this until later, or were you hoping
>>> it wouldn't be a problem?  If it's the former then this is not my
>>> number one priority at the moment, so from my perspective I can wait
>>> until the next release candidate / release.
>> To be completely frank, I was not really worried about this issue, since
>> you had not answered, I thought that maybe the issue was in your test
>> program.
>>
>>> Linux kernel: 2.6.29.4
>>> Xenomai: 2.5-rc2
>>> Adeos: adeos-ipipe-2.6.29.4-x86-2.4-01
>>>
>>> OS: Ubuntu (8.04 with updates)
>>> Hardware:
>>> Intel Core 2 CPU, kernel compiled using processor family 'Pentium-4/etc'
>> compiled for 32 or 64 bits?
>>
>> --
>>                                           Gilles
>>
>>
> 
> 32 bit,

Ok. It turns out that the error is portable, and there is no other way
than to fix the result after the multiplication (trying to round
differently leads to the converse error). So, could you try the
following patch:

diff --git a/include/asm-generic/bits/timeconv.h
b/include/asm-generic/bits/time
index 79060b3..aa595fe 100644
--- a/include/asm-generic/bits/timeconv.h
+++ b/include/asm-generic/bits/timeconv.h
@@ -60,10 +60,17 @@ long long xnarch_ns_to_tsc(long long ns)
 unsigned long long xnarch_divrem_billion(unsigned long long value,
                                         unsigned long *rem)
 {
-       unsigned long long r;
-       r = xnarch_nodiv_ullimd(value, bln_frac.frac, bln_frac.integ);
-       *rem = value - r * 1000000000;
-       return r;
+       unsigned long long q;
+       unsigned r;
+
+       q = xnarch_nodiv_ullimd(value, bln_frac.frac, bln_frac.integ);
+       r = value - q * 1000000000;
+       if (r >= 1000000000) {
+               ++q;
+               r -= 1000000000;
+       }
+       *rem = r;
+       return q;
 }
 #else /* !XNARCH_HAVE_NODIV_LLIMD */
 long long xnarch_ns_to_tsc(long long ns)


-- 
					    Gilles.

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

[Steve]

[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]

2009/8/20 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>

> Steve wrote:
> > On 19/08/2009, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> wrote:
> >> Steve wrote:
> >>> Were you going to delay handling this until later, or were you hoping
> >>> it wouldn't be a problem?  If it's the former then this is not my
> >>> number one priority at the moment, so from my perspective I can wait
> >>> until the next release candidate / release.
> >> To be completely frank, I was not really worried about this issue, since
> >> you had not answered, I thought that maybe the issue was in your test
> >> program.
> >>
> >>> Linux kernel: 2.6.29.4
> >>> Xenomai: 2.5-rc2
> >>> Adeos: adeos-ipipe-2.6.29.4-x86-2.4-01
> >>>
> >>> OS: Ubuntu (8.04 with updates)
> >>> Hardware:
> >>> Intel Core 2 CPU, kernel compiled using processor family
> 'Pentium-4/etc'
> >> compiled for 32 or 64 bits?
> >>
> >> --
> >>                                           Gilles
> >>
> >>
> >
> > 32 bit,
>
> Ok. It turns out that the error is portable, and there is no other way
> than to fix the result after the multiplication (trying to round
> differently leads to the converse error). So, could you try the
> following patch:
>
> diff --git a/include/asm-generic/bits/timeconv.h
> b/include/asm-generic/bits/time
> index 79060b3..aa595fe 100644
> --- a/include/asm-generic/bits/timeconv.h
> +++ b/include/asm-generic/bits/timeconv.h
> @@ -60,10 +60,17 @@ long long xnarch_ns_to_tsc(long long ns)
>  unsigned long long xnarch_divrem_billion(unsigned long long value,
>                                         unsigned long *rem)
>  {
> -       unsigned long long r;
> -       r = xnarch_nodiv_ullimd(value, bln_frac.frac, bln_frac.integ);
> -       *rem = value - r * 1000000000;
> -       return r;
> +       unsigned long long q;
> +       unsigned r;
> +
> +       q = xnarch_nodiv_ullimd(value, bln_frac.frac, bln_frac.integ);
> +       r = value - q * 1000000000;
> +       if (r >= 1000000000) {
> +               ++q;
> +               r -= 1000000000;
> +       }
> +       *rem = r;
> +       return q;
>  }
>  #else /* !XNARCH_HAVE_NODIV_LLIMD */
>  long long xnarch_ns_to_tsc(long long ns)
>
>
> --
>                                             Gilles.
>
Hi,

I have applied the patch and it works - the kernel messages from the
previous patch are no longer produced, and my test program works without
clock_gettime tv_nsec checks.  Thank you.

Just for completeness, are we sure that the value given by r is never more
than 2 billion?  I only ask because the patch only deals with one second
worth of overrun.

Steve

[-- Attachment #2: Type: text/html, Size: 3422 bytes --]

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

[Gilles Chanteperdrix]

Steve wrote:
> 2009/8/20 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org
> <mailto:gilles.chanteperdrix@xenomai.org>>
> 
>     Steve wrote:
>     > On 19/08/2009, Gilles Chanteperdrix
>     <gilles.chanteperdrix@xenomai.org
>     <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
>     >> Steve wrote:
>     >>> Were you going to delay handling this until later, or were you
>     hoping
>     >>> it wouldn't be a problem?  If it's the former then this is not my
>     >>> number one priority at the moment, so from my perspective I can wait
>     >>> until the next release candidate / release.
>     >> To be completely frank, I was not really worried about this
>     issue, since
>     >> you had not answered, I thought that maybe the issue was in your test
>     >> program.
>     >>
>     >>> Linux kernel: 2.6.29.4
>     >>> Xenomai: 2.5-rc2
>     >>> Adeos: adeos-ipipe-2.6.29.4-x86-2.4-01
>     >>>
>     >>> OS: Ubuntu (8.04 with updates)
>     >>> Hardware:
>     >>> Intel Core 2 CPU, kernel compiled using processor family
>     'Pentium-4/etc'
>     >> compiled for 32 or 64 bits?
>     >>
>     >> --
>     >>                                           Gilles
>     >>
>     >>
>     >
>     > 32 bit,
> 
>     Ok. It turns out that the error is portable, and there is no other way
>     than to fix the result after the multiplication (trying to round
>     differently leads to the converse error). So, could you try the
>     following patch:
> 
>     diff --git a/include/asm-generic/bits/timeconv.h
>     b/include/asm-generic/bits/time
>     index 79060b3..aa595fe 100644
>     --- a/include/asm-generic/bits/timeconv.h
>     +++ b/include/asm-generic/bits/timeconv.h
>     @@ -60,10 +60,17 @@ long long xnarch_ns_to_tsc(long long ns)
>      unsigned long long xnarch_divrem_billion(unsigned long long value,
>                                             unsigned long *rem)
>      {
>     -       unsigned long long r;
>     -       r = xnarch_nodiv_ullimd(value, bln_frac.frac, bln_frac.integ);
>     -       *rem = value - r * 1000000000;
>     -       return r;
>     +       unsigned long long q;
>     +       unsigned r;
>     +
>     +       q = xnarch_nodiv_ullimd(value, bln_frac.frac, bln_frac.integ);
>     +       r = value - q * 1000000000;
>     +       if (r >= 1000000000) {
>     +               ++q;
>     +               r -= 1000000000;
>     +       }
>     +       *rem = r;
>     +       return q;
>      }
>      #else /* !XNARCH_HAVE_NODIV_LLIMD */
>      long long xnarch_ns_to_tsc(long long ns)
> 
> 
>     --
>                                                Gilles.
> 
> Hi,
> 
> I have applied the patch and it works - the kernel messages from the
> previous patch are no longer produced, and my test program works without
> clock_gettime tv_nsec checks.  Thank you.
> 
> Just for completeness, are we sure that the value given by r is never
> more than 2 billion?  I only ask because the patch only deals with one
> second worth of overrun.

Yes. The multiplication used to compute q may only be off by one.

-- 
                                          Gilles