>> >> > it seems to me as APC interrupts on ipipe got lost. I have added two >> >> > counters: >> >> > One increments in schedule_linux_call() when a request for a specific >> >> > application >> >> > task is queued. Another one is incremented in lostage_handler() when the >> >> > specific task was waked up. When I output the counter's values after >> >> > tasks have >> >> > freezed the counter of lostage_handler is exactly one value less than >> >> > schedule_linux_call's counter. >> >> > >> >> > And then, when I wake-up APC thread manually all freezed tasks continue >> >> > for a >> >> > moment, until all are freezing again. >> >> >> >> As said above waking APC thread using >> >> >> >> wake_up_process(rthal_apc_servers[smp_processor_id()]); >> >> >> >> does reactivate all Xenomai threads for scheduling. Incontrast using >> >> >> >> rthal_apc_schedule(lostage_apc); >> >> >> >> does not help. So it seems as APC interrupt is pending but won't be >> >> executed. >> >> >> >> Any idea? >> > >> > Do you have the same issue if you run a kernel patched with Xenomai >> > and without the PREEMPT_RT patch? >> >> No, without PREEMPT_RT the problem did not yet occur. > > Have you tried to follow the path from rthal_apc_schedule to > rthal_apc_handler to see where the notification gets lost?
I am about to do that. Unfortunately I am not very familiar with ipipe implementation. Do you know if there are some tracing or debug features that could help me here? > Also note that calling wake_up_process from primary mode is not a > good idea. Thank for the hint. Actually I had used wake_up_process() only from 2nd domain to test if this APC thread was broken or not. Thanks and regards, Christoph _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
