On Wed, 2007-04-04 at 17:10 +0200, Jack Whorn wrote: > > Changeset r2092 introduced the sleeping scheduler lock for v2.3.x. > > Hi Philippe, > > I appreciate your help very much! I found and applied the diffs of changeset > r2092. > It seems to work much better now: The system is able to access the hard > disk, as I > see the LED blinking periodically. That`s great! > > Still, I can`t use the keyboard to stop the application by pressing Strg-C. > Also, the text cursor doesn`t blink, so the Linux system seems to be > overloaded > (probably, it`s no longer scheduled). > > So, the Linux-Kernel now seems to be able to run on behalf of a high-priority > task. > Though, it is no longer scheduled as an idle task, which is ok as there is > the highe > r priority-task with the infinite loop. This way, everything acts as expected. >
What you see is your real-time task called "thread" running, nothing else. > Nevertheless, it would be interesting to run a linux shell concurrently. Can > I adjust > linux priority during runtime (or: where do I have to adjust it in the > sources)? > > And btw, where can I look up the keyboard interrupt`s priority (is it > kernel`s priority)? > You may want to read these articles, explaining the basic concept of primary and secondary domains as seen by the native API and all other interfaces, and how this is implementing by the Adeos layer: http://www.xenomai.org/documentation/branches/v2.3.x/pdf/Native-API-Tour-rev-C.pdf http://www.xenomai.org/documentation/branches/v2.3.x/pdf/Life-with-Adeos-rev-B.pdf In short, the infinite loop inside your application runs in primary mode, which starves the regular Linux kernel from CPU and interrupts, so that primary mode remains highly predictable time-wise. For that reason, hitting ^C has no effect when running this loop (no kbd IRQ and no input core polling for kbd event => no driver interaction => no termio handling => no SIGINT ever emitted therefore received by your process). All the CPU is eaten by your thread, and only real-time interrupts are allowed to preempt it from time to time. (Activating CONFIG_XENO_OPT_WATCHDOG would pull the break and stop this loop after 4s btw). You cannot adjust the kernel priority in the Xenomai scale yourself, this would introduce unpredictable latencies. Xenomai does a similar adjustment automatically when a real-time switches to secondary mode (an explanation can be found in the cited docs), but this could be applied to any random Linux task without wrecking the real-time behaviour, so this has not been made possible. To sum up, if you want regular I/O such as keyboard input to be processed by Linux, you need to leave a bit of CPU time to the regular kernel. This is why the infinite loop seems to lock up the box. Rule of thumb: this is not a pure RTOS, but a combo merging a GPOS and a RTOS sub-system to get the best of both worlds, so you need to make sure that both can co-exist together - which does not prevent to one a higher priority over the other - and leaving CPU time to the regular kernel to process regular I/O through normal drivers is part of the requirements. It is possible to develop real-time I/O drivers (RTDM is there for this task), in this case, most of their code is controlled in primary mode by Xenomai, and not by the vanilla Linux kernel. > Thanks a lot, > > Jack > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
