Carsten Spieß wrote: > Hello Philippe, > >>> But this approach didn't work, the higer prio task isn't called unless >>> the lower prio task gives up cpu (by calling e.g. rt_task_yield or >>> nanosleep) (see attached demo source) >> This would basically say that the core does not give any real-time >> guarantee. > I hope this is not the case. >> Please send some demo code showing this. > I've attached it, please remove the rt_task_yield to see the effect. >>> When not being cooperative (removing the rt_task_yield in the demo) >>> my system is reset after some seconds.
This works fine on 2.4-rc4/x86-2.6.22 here, so I need to switch to a similar ppc configuration to try reproducing it. More news later. Please send your kernel .config for 2.4.25 in the meantime. >>> >>> Why isn't my supervising task scheduled? >>> > >> Try enabling the nucleus watchdog (Xenomai debug options). It does kill >> runaway tasks. > O.k. i will try this. You will have to remove the printf() from the low prio task for the nucleus watchdog to detect the runaway situation, otherwise, your task would be considered as being under the control of the Linux scheduler until it issues a blocking Xenomai syscall (which it never does), and therefore escape the watchdog detection. That's the particular case I was talking about. > >> If this works on your setup, then your code must be >> wrong. If it does not trigger, then we need to understand why -- there >> is one case where it may not trigger, but this does not involve any >> breakage in task management. > > Regards Carsten -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
