Thank you all for your patience in explaining me the Xenomai internals ! But obviously we can´t realy track down the problem. Therefore I´ll try to make a short test case out of my code, which will either help you understand my problem or cut the knot in my brain ;-).
I´ll report again next week. Have a nice weekend Roderik > -----Ursprüngliche Nachricht----- > Von: Philippe Gerum [mailto:[email protected]] > Gesendet: Freitag, 8. Mai 2009 12:36 > An: Wildenburg, Roderik RAEK3 MRA > Cc: [email protected]; [email protected] > Betreff: Re: [Xenomai-help] sem_wait increments fault counter > > On Fri, 2009-05-08 at 09:14 +0200, [email protected] > wrote: > > > > > > > > I try to give some more information: In fact it is a > library we are > > > > talking about (let´s call it shmlib). This library > creates a shared > > > > memory and a (named) semaphore which should synchronise the > > > access to > > > > the shared memory. This library (shmlib) is linked with Xenomai > > > > posix-library, so all posix-calls within shmlib should > be handled by > > > > Xenomai. > > > > > > Well, not quite. Linking is not enough. To actually use > Xenomai posix > > > library calls, you have to pass the bunch of -Wl,--wrap > > > options to gcc, > > > which you get when calling xeno-config --posix-ldflags. > Is it what you > > > are doing. > > > > Not exactly, I wrap all posix calls in my library (shmlib) by hand: > > shm_open -> __wrap_shm_open > > So, when linking shmlib with an application the > wrap-options for gcc don´t need to be provided (I hope. And > the linker does not complain). > > > > > This shmlib is linked to different applications (build by > > > > different developers). To "real" Xenomai-applications > with threads > > > > created with pthread_create and to Linux-applications > which do not > > > > use pthread_create (but whose main thread is a Xenomai > thread, if > > > > linked with shmlib, as I learned just now). When such a > > > > Linux-application calls the shmlib synchronisation > > > function, which in > > > > turn calls sem_wait(), the trap 0 counter is incremented, but no > > > > other error or problem occurs. If I comment out the > sem_wait call in > > > > shmlib, the counter isn´t incremented. So my conclusion > was, that > > > > sem_wait causes the trap 0. > > > > > > If the thread using the semaphore was not a Xenomai posix > skin thread, > > > you would not be able to call Xenomai's sem_wait, it > would return -1 > > > with errno set to EPERM. > > > > > > My question may seem a little bit stupid, but are you checking the > > > return value of sem_wait ? > > > > > > > Yes ("sem_wait itself does not return an error") . > > > > > > > > > > Is trap 0 explicitly generated by Xenomay in some error > > > case or is it > > > > "just" a CPU error when executing an illegal > instruction (but where > > > > should this illegal instruction/code come from ?) ? > > > > > > > > By the way: this error also happens with Xenoami 2.4.6. > > > > > > No, Xenomai has no particular reason to voluntarily generate > > > a trap. And > > > this trap probably causes the calling thread to switch to > secondary > > > mode, so this is bad news if it is a thread with actual real-time > > > activities. As Philippe told you, this trap may be due to > > > some Power PC > > > specific behaviour. > > > > No, it is not a real_time thread which causes the trap. > > Excerpt from Xenomai's powerpc core: ksrc/arch/powerpc/hal.c:413 > > static inline int do_exception_event(unsigned event, unsigned > domid, void *data) > { > if (domid == RTHAL_DOMAIN_ID) { > rthal_realtime_faults[rthal_processor_id()][event]++; > > if (rthal_trap_handler != NULL && > rthal_trap_handler(event, domid, data) != 0) > return RTHAL_EVENT_STOP; > } > > return RTHAL_EVENT_PROPAGATE; > } > > The counter reported by /proc/xenomai/faults is the one incremented > above, only if the issuing domain was Xenomai. Since only real-time > threads may live at that stage, along with Xenomai IRQ handlers, this > does imply in turn that only a real-time thread may have caused such > trap, provided your initial blame on sem_wait() is right. Really. > > > It is just a Linux application which has been linked with my library > > and therefore becomes a Xenomai thread (but probably in secondary > > > mode ?). > > Faults happening in secondary mode are not reported > by /proc/xenomai/faults, precisely because they do not require any > special care from Xenomai, and are simply passed down to the Linux > kernel by the interrupt pipeline. > > > > -- > Philippe. > > > -------------------------------------------------------- manroland AG Vorsitzender des Aufsichtsrates: Hanno C. Fiedler Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592 USt-Ident-Nr. DE 250200933 _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
