> What bothers me, is that we should not even be able to > read /proc/xenomai/sched from an unrelated shell, in case we had a > runaway primary or even secondary SCHED_FIFO task. (IIRC, Roderik is > running Xenomai over a single core ppc board, mpc52xx/icecube). >
Yes this is amazing. The stuck task seems just to be marked running, but isn´t really consuming CPU. Or could the linux kernel also be stuck at the callers prio and therefore execute other syscalls? (Or the task is simply running very often (every time we look at /proc/xenomai sched), so it just seems to be stuck at R). Another irregularity we observed after we replaced the select-call by a poll-call: In this case everything went fine apart from that mode switches and context switches in /proc/xenomai/stat weren´t incremented any more, even though we are sure that the task is running and yielding CPU. Roderik -------------------------------------------------------- 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
