Re: [Xenomai-core] Kernel crash with Xenomai (caused by fork?)
Hi, I've tried a more defensive kernel setup & your patch (no.6). The lockup is still there. It happens after a realtime task is started, though I was unable to track exactly when - it does not crash in a debugger, does not crash with strace, breaks SysRq, and printing log messages seems to be delayed (despite flushing). I tried changing the application code (like using more default flags when creating a task, etc). But I did not find a workaround. I've put the kernel on the web again, including the config (the one that contains "xenomaidp6"). Maybe it might help to track down the bug... Maybe not. Do you have any ideas how to work it around ? Thanks Tomas Tomas Kalibera wrote: > Gilles Chanteperdrix wrote: > >> > Of course, we are looking for all bugs. But please tell me: do you get >> > the lock-up even before fork is called ? If not, could you verify that >> > at least some Xenomai programs run correctly, for instance latency ? >> > Looking at the code, I think I found a bug, but I doubt it could cause a >> > lockup. The definition of VM_PINNED in include/linux/mm.h collides with >> > another bit used by Linux, so this defintion should be changed from: >> > #define VM_PINNED 0x0800 >> > to: >> > #define VM_PINNED 0x1000 >> >> Here comes a 6th patch for this bug, (patch 6 includes patch 5). >> >> >> > I've tested the 6th patch, the lockup is still there. > As far as I can observe, it behaves exactly like with the 5th patch. > > Tomas > > > > > ___ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core > ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
Gilles Chanteperdrix wrote: > On Fri, Apr 4, 2008 at 4:33 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote: >> Gilles Chanteperdrix wrote: >> >>> Right. We are approximating a fraction with another fraction. But my >>> first impression remains: I do not like the idea of making >>> xnarch_ns_to_tsc wrong because xnarch_tsc_to_ns is wrong. >>> >> Well, my first impression was originally the same: If we still need llimd >> in the ns-to-tsc patch, then we should keep the precise way. But that was >> wrong as this thread demonstrated. We have to ensure that >> ns_to_tsc(tsc_to_ns(x)) remains x with only minor last-digit errors. So >> either use scaled math parameters in both ways or fall back to the original >> calculation. > > Now that I think about it, this scaled math approach is about taking > an approximation of the CPU frequency, which is already approximative. > So, I will not oppose longer to your patch. > Ok, so I take this for a green light to commit too. Please commit. >> However the final decision for 2.5 is (pro or contra scaled math), at least >> for 2.4.x we have to fix things now without turning the upside down. That >> means apply my patch or revert scaled-math optimizations for all archs. > > > -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
On Fri, Apr 4, 2008 at 4:33 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote: > Gilles Chanteperdrix wrote: > > > Right. We are approximating a fraction with another fraction. But my > > first impression remains: I do not like the idea of making > > xnarch_ns_to_tsc wrong because xnarch_tsc_to_ns is wrong. > > > > Well, my first impression was originally the same: If we still need llimd > in the ns-to-tsc patch, then we should keep the precise way. But that was > wrong as this thread demonstrated. We have to ensure that > ns_to_tsc(tsc_to_ns(x)) remains x with only minor last-digit errors. So > either use scaled math parameters in both ways or fall back to the original > calculation. Now that I think about it, this scaled math approach is about taking an approximation of the CPU frequency, which is already approximative. So, I will not oppose longer to your patch. > > However the final decision for 2.5 is (pro or contra scaled math), at least > for 2.4.x we have to fix things now without turning the upside down. That > means apply my patch or revert scaled-math optimizations for all archs. -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
Gilles Chanteperdrix wrote: Right. We are approximating a fraction with another fraction. But my first impression remains: I do not like the idea of making xnarch_ns_to_tsc wrong because xnarch_tsc_to_ns is wrong. Well, my first impression was originally the same: If we still need llimd in the ns-to-tsc patch, then we should keep the precise way. But that was wrong as this thread demonstrated. We have to ensure that ns_to_tsc(tsc_to_ns(x)) remains x with only minor last-digit errors. So either use scaled math parameters in both ways or fall back to the original calculation. However the final decision for 2.5 is (pro or contra scaled math), at least for 2.4.x we have to fix things now without turning the upside down. That means apply my patch or revert scaled-math optimizations for all archs. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
On Fri, Apr 4, 2008 at 3:57 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote: > > Gilles Chanteperdrix wrote: > > > On Fri, Apr 4, 2008 at 3:25 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote: > > > > > Gilles Chanteperdrix wrote: > > > > > > > > > > On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > Sebastian Smolorz wrote: > > > > > > > > > > > > > > > > > > > > > Jan Kiszka wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Sebastian Smolorz wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jan Kiszka wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This patch may do the trick: it uses the inverted tsc-to-ns > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > function > > > > > > > > > > > > instead of the frequency-based one. Be warned, it is totally > untested > > > > > > > > > > > > inside > > > > > > > > > > > > Xenomai, I just ran it in a user space test program. But it may give > an > > > > > idea. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Your patch needed two minor corrections (ns instead of ts in > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > functions > > > > > > > > > > > > xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of > > > > > > > > > > > > latency > > > > > > > > > > > > -t1 seems to prove your bug-fix: There seems to be no drift. > > > > > > > > > > > > > > > > > > > > > > > That's good to hear. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If I got your patch correctly, it doesn't make > xnarch_tsc_to_ns > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > more > > > > > > > > > > > > precise but introduces a new function xnarch_ns_to_tsc() which is > also > > > > > > > > > > > > less > > > > > > > > > > > > precise than the generic xnarch_ns_to_tsc(), right? > > > > > > > > > > > > > > > > > > > > > > > Yes. It is now precisely the inverse imprecision, so to say. :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So isn't there still the danger of getting wrong values when > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > calling > > > > > > > > > > > > xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()? > > > > > > > > > > > > > > > > > > > > > > > Only if the user decides to implement his own conversion. > Xenomai > > > > > > > > > > > > > > > > > > > > > > > > > with > > > > > > > > > > > > all its skins and both in kernel and user space should always run > > > > > > > > > > > > through > > > > > > > > > > > > the xnarch_* path. > > > > > > > > > > > > > > > > OK, would you commit the patch? > > > > > > > > > > > > > > > > > > > > > > > Will do unless someone else has concerns. Gilles, Philippe? ARM and > > > > > Blackfin then need to be fixed similarly, full patch attached. > > > > > > > > > > > > > > Well, I am sorry, but I do not like this solution; > > > > - the aim of scaled math is to avoid divisions, and with this patch we > > > > end up using divisions; > > > > > > > > > > > Please check again, no new division due to my patch, just different > > > parameters for the existing one. > > > > > > > I just checked your patch rapidly, but saw that xnarch_ns_to_tsc was > > using llimd, so does use division. My fast_llimd could be used to > > replace both the llimd calls in xnarch_tsc_to_ns and xnarch_ns_to_tsc. > > > > > > > > > > > > > > > > > - with scaled math we do wrong calculations, and making a wrong > > > > xnarch_ns_to_tsc only works for values which should be passed to > > > > xnarch_tsc_to_ns. > > > > > > > > > > > IMHO, the error is within the range of the clock's precision, if not > even > > > below. So struggling for mathematically precise conversion of imprecise > > > physical values makes no sense to me. Therefore I once proposed the > > > scaled-math optimization. > > > > > > > Now that I have understood what really happens, I disagree with this > > approach. Take the implementation of clock_gettime (or > > rtdm_clock_read, for that matter). They basically do > > xnarch_tsc_to_ns(ipipe_read_tsc()). The relative error may be small, > > but in the very frequent use case of substracting two results of > > consecutive reads of ipipe_read_tsc, the result of the substraction is > > essentially garbage, because the result of the substraction may be of > > the same order as the absolute error of the conversion. And I insist, > > this use case of clock_gettime or rtdm_clock_read is a very realistic > > use case. > > > > This use case is valid, but I don't see the error scenario you sketch: The > error of the conversion is only relevant for large deltas, > tsc_to_ns(B)-tsc_to_ns(A)=B-A for any small B-A. Cornelius' test nicely > showed constantly increasing deviation, not something that jumped around. > Essentially, we are just replacing > > xnarch_llimd(ts, 10, RTHAL_CPU_FREQ); > > with > >
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
Gilles Chanteperdrix wrote: On Fri, Apr 4, 2008 at 3:25 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote: Gilles Chanteperdrix wrote: On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote: Sebastian Smolorz wrote: Jan Kiszka wrote: Sebastian Smolorz wrote: Jan Kiszka wrote: This patch may do the trick: it uses the inverted tsc-to-ns function instead of the frequency-based one. Be warned, it is totally untested inside Xenomai, I just ran it in a user space test program. But it may give an idea. Your patch needed two minor corrections (ns instead of ts in functions xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of latency -t1 seems to prove your bug-fix: There seems to be no drift. That's good to hear. If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more precise but introduces a new function xnarch_ns_to_tsc() which is also less precise than the generic xnarch_ns_to_tsc(), right? Yes. It is now precisely the inverse imprecision, so to say. :) So isn't there still the danger of getting wrong values when calling xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()? Only if the user decides to implement his own conversion. Xenomai with all its skins and both in kernel and user space should always run through the xnarch_* path. OK, would you commit the patch? Will do unless someone else has concerns. Gilles, Philippe? ARM and Blackfin then need to be fixed similarly, full patch attached. Well, I am sorry, but I do not like this solution; - the aim of scaled math is to avoid divisions, and with this patch we end up using divisions; Please check again, no new division due to my patch, just different parameters for the existing one. I just checked your patch rapidly, but saw that xnarch_ns_to_tsc was using llimd, so does use division. My fast_llimd could be used to replace both the llimd calls in xnarch_tsc_to_ns and xnarch_ns_to_tsc. - with scaled math we do wrong calculations, and making a wrong xnarch_ns_to_tsc only works for values which should be passed to xnarch_tsc_to_ns. IMHO, the error is within the range of the clock's precision, if not even below. So struggling for mathematically precise conversion of imprecise physical values makes no sense to me. Therefore I once proposed the scaled-math optimization. Now that I have understood what really happens, I disagree with this approach. Take the implementation of clock_gettime (or rtdm_clock_read, for that matter). They basically do xnarch_tsc_to_ns(ipipe_read_tsc()). The relative error may be small, but in the very frequent use case of substracting two results of consecutive reads of ipipe_read_tsc, the result of the substraction is essentially garbage, because the result of the substraction may be of the same order as the absolute error of the conversion. And I insist, this use case of clock_gettime or rtdm_clock_read is a very realistic use case. This use case is valid, but I don't see the error scenario you sketch: The error of the conversion is only relevant for large deltas, tsc_to_ns(B)-tsc_to_ns(A)=B-A for any small B-A. Cornelius' test nicely showed constantly increasing deviation, not something that jumped around. Essentially, we are just replacing xnarch_llimd(ts, 10, RTHAL_CPU_FREQ); with xnarch_llimd(ts, xnarch_tsc_scale, 1
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
On Fri, Apr 4, 2008 at 3:25 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote: > > Gilles Chanteperdrix wrote: > > > On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote: > > > > > Sebastian Smolorz wrote: > > > > > > > > > > Jan Kiszka wrote: > > > > > > > > > > > > > Sebastian Smolorz wrote: > > > > > > > > > > > > > > > > Jan Kiszka wrote: > > > > > > > > > > > > > > > > > > > This patch may do the trick: it uses the inverted tsc-to-ns > function > > > > > > > > > > > > > > > > > > > > > > > > > instead of the frequency-based one. Be warned, it is totally untested > inside > > > Xenomai, I just ran it in a user space test program. But it may give an > > > idea. > > > > > > > > > > > > > > > > > > Your patch needed two minor corrections (ns instead of ts in > functions > > > > > > > > > > > > > > > > > > xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of > latency > > > -t1 seems to prove your bug-fix: There seems to be no drift. > > > > > > > > > > > > That's good to hear. > > > > > > > > > > > > > > > > > > > > > If I got your patch correctly, it doesn't make xnarch_tsc_to_ns > more > > > > > > > > > > > > > > > > > > precise but introduces a new function xnarch_ns_to_tsc() which is also > less > > > precise than the generic xnarch_ns_to_tsc(), right? > > > > > > > > > > > > Yes. It is now precisely the inverse imprecision, so to say. :) > > > > > > > > > > > > > > > > > > > > > So isn't there still the danger of getting wrong values when > calling > > > > > > > > > > > > > > > > > > xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()? > > > > > > > > > > > > Only if the user decides to implement his own conversion. Xenomai > with > > > > > > > > > > > > all its skins and both in kernel and user space should always run > through > > > the xnarch_* path. > > > > > > > OK, would you commit the patch? > > > > > > > > > > > Will do unless someone else has concerns. Gilles, Philippe? ARM and > > > Blackfin then need to be fixed similarly, full patch attached. > > > > > > > Well, I am sorry, but I do not like this solution; > > - the aim of scaled math is to avoid divisions, and with this patch we > > end up using divisions; > > > > Please check again, no new division due to my patch, just different > parameters for the existing one. I just checked your patch rapidly, but saw that xnarch_ns_to_tsc was using llimd, so does use division. My fast_llimd could be used to replace both the llimd calls in xnarch_tsc_to_ns and xnarch_ns_to_tsc. > > > > > - with scaled math we do wrong calculations, and making a wrong > > xnarch_ns_to_tsc only works for values which should be passed to > > xnarch_tsc_to_ns. > > > > IMHO, the error is within the range of the clock's precision, if not even > below. So struggling for mathematically precise conversion of imprecise > physical values makes no sense to me. Therefore I once proposed the > scaled-math optimization. Now that I have understood what really happens, I disagree with this approach. Take the implementation of clock_gettime (or rtdm_clock_read, for that matter). They basically do xnarch_tsc_to_ns(ipipe_read_tsc()). The relative error may be small, but in the very frequent use case of substracting two results of consecutive reads of ipipe_read_tsc, the result of the substraction is essentially garbage, because the result of the substraction may be of the same order as the absolute error of the conversion. And I insist, this use case of clock_gettime or rtdm_clock_read is a very realistic use case. -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
Jan Kiszka wrote: Gilles Chanteperdrix wrote: On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote: Sebastian Smolorz wrote: Jan Kiszka wrote: Sebastian Smolorz wrote: Jan Kiszka wrote: This patch may do the trick: it uses the inverted tsc-to-ns function instead of the frequency-based one. Be warned, it is totally untested inside Xenomai, I just ran it in a user space test program. But it may give an idea. Your patch needed two minor corrections (ns instead of ts in functions xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of latency -t1 seems to prove your bug-fix: There seems to be no drift. That's good to hear. If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more precise but introduces a new function xnarch_ns_to_tsc() which is also less precise than the generic xnarch_ns_to_tsc(), right? Yes. It is now precisely the inverse imprecision, so to say. :) So isn't there still the danger of getting wrong values when calling xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()? Only if the user decides to implement his own conversion. Xenomai with all its skins and both in kernel and user space should always run through the xnarch_* path. OK, would you commit the patch? Will do unless someone else has concerns. Gilles, Philippe? ARM and Blackfin then need to be fixed similarly, full patch attached. Well, I am sorry, but I do not like this solution; - the aim of scaled math is to avoid divisions, and with this patch we end up using divisions; Please check again, no new division due to my patch, just different parameters for the existing one. - with scaled math we do wrong calculations, and making a wrong xnarch_ns_to_tsc only works for values which should be passed to xnarch_tsc_to_ns. IMHO, the error is within the range of the clock's precision, if not even below. So struggling for mathematically precise conversion of imprecise physical values makes no sense to me. Therefore I once proposed the scaled-math optimization. But this does not mean that I'm opposing even faster division-less ns_to_tsc with scaled-math parameters, i.e. combining best of both worlds! Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
Gilles Chanteperdrix wrote: On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote: Sebastian Smolorz wrote: Jan Kiszka wrote: Sebastian Smolorz wrote: Jan Kiszka wrote: This patch may do the trick: it uses the inverted tsc-to-ns function instead of the frequency-based one. Be warned, it is totally untested inside Xenomai, I just ran it in a user space test program. But it may give an idea. Your patch needed two minor corrections (ns instead of ts in functions xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of latency -t1 seems to prove your bug-fix: There seems to be no drift. That's good to hear. If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more precise but introduces a new function xnarch_ns_to_tsc() which is also less precise than the generic xnarch_ns_to_tsc(), right? Yes. It is now precisely the inverse imprecision, so to say. :) So isn't there still the danger of getting wrong values when calling xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()? Only if the user decides to implement his own conversion. Xenomai with all its skins and both in kernel and user space should always run through the xnarch_* path. OK, would you commit the patch? Will do unless someone else has concerns. Gilles, Philippe? ARM and Blackfin then need to be fixed similarly, full patch attached. Well, I am sorry, but I do not like this solution; - the aim of scaled math is to avoid divisions, and with this patch we end up using divisions; Please check again, no new division due to my patch, just different parameters for the existing one. - with scaled math we do wrong calculations, and making a wrong xnarch_ns_to_tsc only works for values which should be passed to xnarch_tsc_to_ns. IMHO, the error is within the range of the clock's precision, if not even below. So struggling for mathematically precise conversion of imprecise physical values makes no sense to me. Therefore I once proposed the scaled-math optimization. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
On Fri, Apr 4, 2008 at 12:45 PM, Jan Kiszka <[EMAIL PROTECTED]> wrote:
>
> Sebastian Smolorz wrote:
>
> > Jan Kiszka wrote:
> >
> > > Sebastian Smolorz wrote:
> > >
> > > > Jan Kiszka wrote:
> > > >
> > > > > This patch may do the trick: it uses the inverted tsc-to-ns function
> instead of the frequency-based one. Be warned, it is totally untested inside
> Xenomai, I just ran it in a user space test program. But it may give an
> idea.
> > > > >
> > > >
> > > > Your patch needed two minor corrections (ns instead of ts in functions
> xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of latency
> -t1 seems to prove your bug-fix: There seems to be no drift.
> > > >
> > >
> > > That's good to hear.
> > >
> > >
> > > > If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more
> precise but introduces a new function xnarch_ns_to_tsc() which is also less
> precise than the generic xnarch_ns_to_tsc(), right?
> > > >
> > >
> > > Yes. It is now precisely the inverse imprecision, so to say. :)
> > >
> > >
> > > > So isn't there still the danger of getting wrong values when calling
> xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()?
> > > >
> > >
> > > Only if the user decides to implement his own conversion. Xenomai with
> all its skins and both in kernel and user space should always run through
> the xnarch_* path.
> > >
> >
> > OK, would you commit the patch?
> >
>
> Will do unless someone else has concerns. Gilles, Philippe? ARM and
> Blackfin then need to be fixed similarly, full patch attached.
Well, I am sorry, but I do not like this solution;
- the aim of scaled math is to avoid divisions, and with this patch we
end up using divisions;
- with scaled math we do wrong calculations, and making a wrong
xnarch_ns_to_tsc only works for values which should be passed to
xnarch_tsc_to_ns.
So, I would like to propose again my solution, which is exact, but use
no division. Its drawback is that it makes a few more additions and
multiplications than rthal_llimd, but has no division. If it happens
to be slower than llimd on some platforms (maybe x86 ?), I would use
llimd. After all, if the division is fast, we may be wrong to try and
avoid it.
For the records, here is the code:
typedef struct {
unsigned long long frac;/* Fractionary part. */
unsigned long integ;/* Integer part. */
} u32frac_t;
/* m/d == integ + frac / 2^64 */
static inline void precalc(u32frac_t *const f,
const unsigned long m,
const unsigned long d)
{
f->integ = m / d;
f->frac = div96by32(u32tou64(m % d, 0), 0, d, NULL);
}
unsigned long fast_imuldiv(unsigned long op, u32frac_t f)
{
const unsigned long tmp = (ullmul(op, f.frac >> 32)) >> 32;
if(f.integ)
return tmp + op * f.integ;
return tmp;
}
#define add64and32(h, l, s) do {\
__asm__ ("addl %2, %1\n\t" \
"adcl $0, %0" \
: "+r"(h), "+r"(l) \
: "r"(s)); \
} while(0)
#define add96and64(l0, l1, l2, s0, s1) do { \
__asm__ ("addl %4, %2\n\t" \
"adcl %3, %1\n\t" \
"adcl $0, %0\n\t" \
: "+r"(l0), "+r"(l1), "+r"(l2) \
: "r"(s0), "r"(s1)); \
} while(0)
static inline __attribute_const__ unsigned long long
mul64by64_high(const unsigned long long op, const unsigned long long m)
{
/* Compute high 64 bits of multiplication 64 bits x 64 bits. */
unsigned long long t1, t2, t3;
u_long oph, opl, mh, ml, t0, t1h, t1l, t2h, t2l, t3h, t3l;
u64tou32(op, oph, opl);
u64tou32(m, mh, ml);
t0 = ullmul(opl, ml) >> 32;
t1 = ullmul(oph, ml); u64tou32(t1, t1h, t1l);
add64and32(t1h, t1l, t0);
t2 = ullmul(opl, mh); u64tou32(t2, t2h, t2l);
t3 = ullmul(oph, mh); u64tou32(t3, t3h, t3l);
add64and32(t3h, t3l, t2h);
add96and64(t3h, t3l, t2l, t1h, t1l);
return u64fromu32(t3h, t3l);
}
static inline __attribute_const__ unsigned long long
fast_llimd(const unsigned long long op, const u32frac_t f)
{
const unsigned long long tmp = mul64by64_high(op, f.frac);
if(f.integ)
return tmp + op * f.integ;
return tmp;
}
--
Gilles
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH][SOLO] add sparse support
On Thu, Apr 03, 2008 at 11:37:31AM +0200, Philippe Gerum wrote: > Robert Schwebel wrote: > > This patch adds static analysis support with sparse to the xenomai-solo > > makefiles. To enable sparse checking, use > > > > ./configure --with-sparse[=PATH] > > > > and run 'make sparse' afterwards. I don't have a good idea right now how > > to avoid this extra step; it would be much nicer if every call to > > $(COMPILE) could be substituted by a sparse call plus the original one, > > but I didn't find a good method for that yet that also works with the > > libtool calls. > > > > I have merged this patch series, adapting the Makefiles so that we don't need > any support from configure.in to run sparse. > > Normally, you should be able to run "make [SPARSE=/path/to/sparse] sparse" to > start the analysis. Default path is "sparse". > > Additionally, this now works with out of tree builds and supports mixed > 32/64bit > environments. Great! Thanks. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
This patch may do the trick: it uses the inverted tsc-to-ns function
instead of the frequency-based one. Be warned, it is totally
untested inside Xenomai, I just ran it in a user space test program.
But it may give an idea.
Your patch needed two minor corrections (ns instead of ts in
functions xnarch_ns_to_tsc()) in order to compile. A short run (30
minutes) of latency -t1 seems to prove your bug-fix: There seems to
be no drift.
That's good to hear.
If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more
precise but introduces a new function xnarch_ns_to_tsc() which is
also less precise than the generic xnarch_ns_to_tsc(), right?
Yes. It is now precisely the inverse imprecision, so to say. :)
So isn't there still the danger of getting wrong values when calling
xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()?
Only if the user decides to implement his own conversion. Xenomai with
all its skins and both in kernel and user space should always run
through the xnarch_* path.
OK, would you commit the patch?
Will do unless someone else has concerns. Gilles, Philippe? ARM and
Blackfin then need to be fixed similarly, full patch attached.
Jan
---
ChangeLog|7 +++
include/asm-arm/bits/init.h |3 ++-
include/asm-arm/bits/pod.h |7 +++
include/asm-blackfin/bits/init.h |3 ++-
include/asm-blackfin/bits/pod.h |7 +++
include/asm-x86/bits/init_32.h |3 ++-
include/asm-x86/bits/init_64.h |3 ++-
include/asm-x86/bits/pod_32.h|7 +++
include/asm-x86/bits/pod_64.h|7 +++
9 files changed, 43 insertions(+), 4 deletions(-)
Index: b/include/asm-x86/bits/init_32.h
===
--- a/include/asm-x86/bits/init_32.h
+++ b/include/asm-x86/bits/init_32.h
@@ -73,7 +73,7 @@ int xnarch_calibrate_sched(void)
static inline int xnarch_init(void)
{
- extern unsigned xnarch_tsc_scale, xnarch_tsc_shift;
+ extern unsigned xnarch_tsc_scale, xnarch_tsc_shift, xnarch_tsc_divide;
int err;
err = rthal_init();
@@ -89,6 +89,7 @@ static inline int xnarch_init(void)
xnarch_init_llmulshft(10, RTHAL_CPU_FREQ,
&xnarch_tsc_scale, &xnarch_tsc_shift);
+ xnarch_tsc_divide = 1 << xnarch_tsc_shift;
err = xnarch_calibrate_sched();
Index: b/include/asm-x86/bits/init_64.h
===
--- a/include/asm-x86/bits/init_64.h
+++ b/include/asm-x86/bits/init_64.h
@@ -70,7 +70,7 @@ int xnarch_calibrate_sched(void)
static inline int xnarch_init(void)
{
- extern unsigned xnarch_tsc_scale, xnarch_tsc_shift;
+ extern unsigned xnarch_tsc_scale, xnarch_tsc_shift, xnarch_tsc_divide;
int err;
err = rthal_init();
@@ -86,6 +86,7 @@ static inline int xnarch_init(void)
xnarch_init_llmulshft(10, RTHAL_CPU_FREQ,
&xnarch_tsc_scale, &xnarch_tsc_shift);
+ xnarch_tsc_divide = 1 << xnarch_tsc_shift;
err = xnarch_calibrate_sched();
Index: b/include/asm-x86/bits/pod_32.h
===
--- a/include/asm-x86/bits/pod_32.h
+++ b/include/asm-x86/bits/pod_32.h
@@ -25,6 +25,7 @@
unsigned xnarch_tsc_scale;
unsigned xnarch_tsc_shift;
+unsigned xnarch_tsc_divide;
long long xnarch_tsc_to_ns(long long ts)
{
@@ -32,6 +33,12 @@ long long xnarch_tsc_to_ns(long long ts)
}
#define XNARCH_TSC_TO_NS
+long long xnarch_ns_to_tsc(long long ns)
+{
+ return xnarch_llimd(ns, xnarch_tsc_divide, xnarch_tsc_scale);
+}
+#define XNARCH_NS_TO_TSC
+
#include
#include
Index: b/include/asm-x86/bits/pod_64.h
===
--- a/include/asm-x86/bits/pod_64.h
+++ b/include/asm-x86/bits/pod_64.h
@@ -24,6 +24,7 @@
unsigned xnarch_tsc_scale;
unsigned xnarch_tsc_shift;
+unsigned xnarch_tsc_divide;
long long xnarch_tsc_to_ns(long long ts)
{
@@ -31,6 +32,12 @@ long long xnarch_tsc_to_ns(long long ts)
}
#define XNARCH_TSC_TO_NS
+long long xnarch_ns_to_tsc(long long ns)
+{
+ return xnarch_llimd(ns, xnarch_tsc_divide, xnarch_tsc_scale);
+}
+#define XNARCH_NS_TO_TSC
+
#include
#include
Index: b/include/asm-arm/bits/init.h
===
--- a/include/asm-arm/bits/init.h
+++ b/include/asm-arm/bits/init.h
@@ -67,7 +67,7 @@ int xnarch_calibrate_sched(void)
static inline int xnarch_init(void)
{
- extern unsigned xnarch_tsc_scale, xnarch_tsc_shift;
+ extern unsigned xnarch_tsc_scale, xnarch_tsc_shift, xnarch_tsc_divide;
int err;
err = rthal_init();
@@ -77,6 +77,7 @@ static inline int xnarch_init(void)
xnarch_init_llmulshft(10, RTHAL_CPU_FREQ,
&xnarch_tsc_scale, &xnarch_tsc_shift);
+ xnarch_tsc_divide = 1 << xnarch_tsc_shift;
err = xnarch_calibrate_sched();
Index: b/include/asm-arm/bi
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
Jan Kiszka wrote: > Sebastian Smolorz wrote: >> Jan Kiszka wrote: >>> This patch may do the trick: it uses the inverted tsc-to-ns function >>> instead of the frequency-based one. Be warned, it is totally untested >>> inside Xenomai, I just ran it in a user space test program. But it >>> may give an idea. >> >> Your patch needed two minor corrections (ns instead of ts in functions >> xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of >> latency -t1 seems to prove your bug-fix: There seems to be no drift. > > That's good to hear. > >> If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more >> precise but introduces a new function xnarch_ns_to_tsc() which is also >> less precise than the generic xnarch_ns_to_tsc(), right? > > Yes. It is now precisely the inverse imprecision, so to say. :) > >> So isn't there still the danger of getting wrong values when calling >> xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()? > > Only if the user decides to implement his own conversion. Xenomai with > all its skins and both in kernel and user space should always run > through the xnarch_* path. OK, would you commit the patch? -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
