Li Yi wrote:
Thanks for the clarification.
I added a sleep(1) before read the "/proc/interrupts", and the timer
interrupts for Linux kernel really got "Replayed". The system time
catches up with the wall clock.
But still some question:
On Thu, 2006-04-20 at 10:19 +0200, Philippe Gerum wrote:
In the particular case of multi-ms processing, I would likely suggest to
move it to a thread running in secondary mode without interrupt
shielding, so that Linux asynchronous activities such as interrupt
handling would still be possible, at the expense of a lesser execution
time predictability of such processing though.
In my test, I am using rt_timer_spin() to simulate the real-time
workload. And "/proc/xenomai/stat" shows "MSW" as "1/1", and in one test
loop, there is no change for "MSW". So I concluded my test case is
running in secondary mode. And my "Interrupt shield support"
configuration is _not_ select. But it looks the Linux kernel does _not_
handle timer interrupt while the real-time task is running. Did I miss
anything?
rt_timer_spin() is a busy-waiting service, and your measurement task
never relinquishes the CPU while processing. I would bet that you set up
a very high (maximum?) SCHED_FIFO priority to the Xenomai task, which
did not allow the IRQ thread to run.
i.e. On the Blackfin architecture, Adeos scales the IRQ thread priority
from SCHED_FIFO(50) to SCHED_FIFO(50 + (IVG13-IVG7)), which would have a
lesser priority than anything above SCHED_FIFO(56).
You may want to make your measurement thread sleep() for a while before
looking at the final tick counter; this would make sure that the IRQ
threads have been given enough time to catch up and process all pending
ticks they have in their log. Btw, did you activate CONFIG_PREEMPT?
Er, sorry. There's no CONFIG_PREEMPT on Blackfin yet.
Thanks,
-Li Yi (Adam)
--
Philippe.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
