Wolfgang Grandegger wrote:
> Wolfgang Grandegger wrote:
>> Hi Gilles,
>>
>> Gilles Chanteperdrix wrote:
>>> Wolfgang Grandegger wrote:
>>>> I'm also puzzled why pthread_setschedparam() does make a mode switch
>>>> to secondary mode (sometimes).
>>> That is normal. The glibc caches threads priority value, so we have to
>>> call __real_pthread_setschedparam to update them. This issue has been
>>> solved differently on trunk, but unfortunately, we can not backport this
>>> modification on v2.4.x branch.
>> To get you right. With v2.4.x it is not possible with the POSIX skin to
>> change the priority of a real-time thread in the primary mode without
>> loosing determinism (because it will switch to secondary mode). What
>> options do I have?
>
> I gave Xenomai trunk a try and pthread_setschedparam() does not switch
> to secondary mode any more on my PowerPC test system. Nice, I just get
> an Oops in thread_delete from time to time. More on that issue later.
> For my ARM i.mx31 system, a need a few patches to get the Xenomai src's
> compiled:
>
> Index: include/asm-generic/bits/bind.h
> ===================================================================
> --- include/asm-generic/bits/bind.h (revision 4450)
> +++ include/asm-generic/bits/bind.h (working copy)
> @@ -72,7 +72,7 @@
> err = XENOMAI_SYSCALL1(__xn_sys_current, ¤t);
> if (err) {
> fprintf(stderr, "Xenomai: error obtaining handle for current "
> - "thread: %s\n", strerror(err));
> + "thread: %s\n", strerror(-err));
> exit(1);
> }
> __xeno_set_current(current);
> Index: include/asm-arm/syscall.h
> ===================================================================
> --- include/asm-arm/syscall.h (revision 4450)
> +++ include/asm-arm/syscall.h (working copy)
> @@ -228,7 +228,7 @@
> volatile unsigned long long *const tscp = __xn_tscinfo.u.fr.tsc;
> volatile unsigned *const counterp = __xn_tscinfo.u.fr.counter;
> const unsigned mask = __xn_tscinfo.u.fr.mask;
> - register unsigned long long after, before;
> + register unsigned long long result;
> unsigned counter;
>
> __asm__ ("ldmia %1, %M0\n": "=r"(result): "r"(tscp), "m"(*tscp));
>
>
> When I then start my application or cyclictest I get:
>
> -bash-3.2# ./cyclictest -n
> Xenomai: error obtaining handle for current thread: Operation not permitted
>
> As the latency program works fine, it seems to be a problem with the
> POSIX skin. Any idea what it is?
First of all, are you sure that all parts were properly updated and in
sync now?
The error means that something went wrong during the
__wrap_pthread_setschedparam execution on __init_posix_interface. More
precisely, we lack the shadow thread for the current (main) thread for
unknown reasons.
Could you fire up gdb, step through this and check (looking at
/proc/xenomai/sched) what happens on ARM here? x86 was fine the last
time I checked (will recheck later today).
Jan
--
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
