[fusion] userspace POSIX skin

Philippe Gerum rpm at xenomai.org
Fri Jun 17 16:00:42 CEST 2005

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> ...
>>> Now, with fusion release 0.8 and kernel, I even 
>>> get a fatal lock-up after "Hit ^C ...". Normal fusion latency tests 
>>> and other stuff seems to run flawlessly.
>>> Any ideas where to search?
>> If it's a hard lockup, nmi_watchdog=2 lapic=1 would help us getting a 
>> backtrace, hopefully.
> I just checked this on a different system without getting in troubles. I 
> also noticed (as a did a clean check-out) that accuracy_rt is not 
> automatically (re-)build.

True. In fact, demos/ dirs are never built automatically basically 
because they provide external Makefiles, which are there to help users 
figuring out how to compile-link their own code against the demonstrated 
support out of the autoconfiscated tree.

  I suspect now that I used an older build of
> the demo with the recent fusion core on my test system at home. Will 
> check this again this evening.
>>> ...
>>> PS: Regarding signal support, a topic that also comes up again with 
>>> the POSIX skin: Is there a chance to get adeos fixed with respect to 
>> Actually ADEOS_SIGNAL_PROCESS is not to fix, it is to be deprecated. 
>> It does the best it can do intercept signals, but unfortunately, from 
>> a place in the kernel where not all signals are flowing through.
> That's a pity.
>>  This would allow skins to provide signal
>>> forwarding (or dropping) handlers in primary context without the need to
>>> switch to secondary first. Or am I overseeing some already applied fix?
>> I think we won't be able to do that. The reason stands in the fact 
>> that not all signals are user-generated, but some of them are sent by 
>> the kernel itself - those are the ones which don't go through the 
>> ADEOS_SIGNAL interception. Some of them even carry stateful semantics, 
>> such as SIGTRAP used by ptrace(), which needs to be acknowledged by 
>> the debuggee to its parent debugger. There are other examples 
>> involving signals used by the kernel for internal housekeeping chores, 
>> like group termination signals. IOW, since the kernel sometimes relies 
>> on specific signals to be actually processed, we can't just decide to 
>> filter them out, whatever our otherwise good reason is. In this 
>> respect and elsewhere, fusion's motto is and has always been: work 
>> _with_ Linux as much as possible, not against or aside of.
> Ok, I see. That's likely some of the few drawbacks of having a normal 
> linux process attached to a real-time thread. In fact, I thought of 
> having such a signal filter as a safety feature: after my critical 
> real-time thread has been thoroughly debugged (using signals ;)), I 
> would like to "freeze" it with respect to mode switches. This would 
> prevent that the user can accidentally kick it out of real-time (e.g. by 
> starting to shutdown the related process) and instead allow the thread 
> to handle the user's desire in a deterministic way (e.g. first shutdown 
> some critical hardware safely within primary mode).

If it's about mode switch detection, then I'd suggest something along 
those lines:

void mode_switch_handler (int sig)
	abort(); /* Or anything else a bit less lethal :o> */


void foo_thread (void *cookie)
	/* Kick this thread with SIGXCPU each time it is
	   switched to secondary mode. */
	for (;;) {
		/* ... */

main ()

This said, this does not handle the pre-switch work you may want to do 
for shutting down the hardware since the handler runs after the switch 
has occurred, but if cleaning the things up after the switch is still an 
option, then it would work as is. Nb: you may switch back to primary in 
the signal handler, fusion allows this.

> Other topic: I browsed a bit through the userspace lib of the posix 
> skin. At this chance, I stumbled over the lock implementation to protect 
> the pthread=>rt-pthread mapping. Do you think it is ok to have a 
> spinning lock without preemption protection? This is at least how I read 
> the implementation ATM. Consider, e.g., a normal linux thread creating a 
> new rt-pthread. Now, while holding __jhash_lock, it gets preempted by an 
> already running rt-pthread. That thread may also like to access the 
> lock. It will then start spinning endlessly because, due to missing 
> priority inheritance or ceiling, it will never let the non-rt-thread 
> release the lock again. Right?

Absolutely, good spot! :o) I'm working on some integrated service to 
implement a safe rw lock with the smallest possible overhead. 
Unfortunately, POSIX does not define something like 
pthread_getspecific_from(pthread_t thread), so we need to fiddle with 
uselessly complex synchronization just to map a pthread_t to a fusion 
thread descriptor. Mfff...

> Jan
> _______________________________________________
> RTAI mailing list
> RTAI at rtai.org
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai



More information about the Rtai mailing list