Re: [Xenomai-help] pthread cancelation and scheduling magics

[Philippe Gerum <rpm@xenomai.org>]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Gilles Chanteperdrix wrote:
>>> 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, &current);
>>>>  	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?
>>> What version of gcc are you using ? When trying to get xenomai running
>>> on an ARM platform, I found out that gcc 4.3.1 and 4.3.2 have a bug on
>>> ARM which thrashes the parameters passed to  some xenomai syscalls.
>>>
>> A common issue happens when pthread_self() is inlined in the syscall arg list.
>> Early gcc 4.x for powerpc has this problem; never tried with newer releases, but
>> rather made sure to use a temporary variable to pass this value to the syscall.
> 
> The issue on arm is a similar issue: the problem comes from the
> "mode_buf" parameter now passed to pthread_create which clobbers the
> register r0, normally used to pass the syscall number.
> 
> I am still trying to figure out if it is a bug in Xenomai's syscall
> inline assembly, or a bug in gcc or binutils. And even if it is a bug in
> the toolchain, I am afraid we will have to find a workaround in the
> syscall inline assmbley anyway.
> 

Yes.

-- 
Philippe.