Hi Wolfgang, On Mon, 2004-07-19 at 17:40, Wolfgang Grandegger wrote: > Hello, > > when I load rtai_lxrt.o on my PowerPC system, the system hangs after the > first lxrt_context_switch(), which happens in the migration handler > after switching to real-time. I do still not understand in detail what's > going on there and therefore some brief description on how LXRT works > would help. Does some documentation exist?
Doc...what? I've heard from ancient fairy tales that "documentation" is some strange animal with a nice jacket on it, living in civilized software territories, but never saw one yet :o> > I'm epecially interrested to > know, what the purpose of the various kernel threads is, e.g. kthread_b, > kthread_m and thread_fun(). To grasp the basic mechanism, track steal_from_linux() and give_back_to_linux(). steal_from_linux() does like this: - wake kthread_b up to perform the transition for "current", blocking the latter in TASK_UNINTERRUPTIBLE state (i.e. aliased to TAS<K_HARDREALTIME -- this why you get the massive load average for Linux when LXRT runs, btw). - once resumed, kthread_b()'s body escalates the request to the RTAI domain(it's mandatory otherwise there would be a consistency issue with schedule() being called over the RTAI domain from the user-space re-entry path, especially with a preemptible kernel); at that point, the migrating task is out of the Linux runqueue since, well, kthread_b() runs :o> - lxrt_migration_handler() recycles the migrating task's %eip and %esp from the Linux per-thread struct in order to bring it back running, but this time over the RTAI domain and controlled by the RTAI scheduler. This is the purpose of fast_schedule() which in turns triggers lxrt_context_switch(). The latter just restores the task's MMU context and does a lightweight switch. The resumption point is right behind schedule() in steal_from_linux() since we recycled the previous %eip and %esp when the migrating task was blocked. give_back_to_linux() is somewhat simpler: - send a service request to the Linux domain (over Adeos, it's built over the virtual IRQ stuff) so that wake_up_srq_handler() is called when Linux gets back in control; this handler will call wake_up_process() for the task migrating back to the Linux domain. - block rt_current RTAI-wise, then rt_schedule(). At some point in time, the idle RT task (rt_linux_task) will be back on this code impersonating the softened Linux task, and will run __adeos_schedule_back_root() to finalize the transition (basically: run Linux's scheduling tail code). The latter is required because we did not recover execution as a result of calling schedule(), but because RTAI did it its own way, so we need to perform the Linux scheduling tail by hand. Well, the above is the survival kit in the LXRT space. The other crucial point is coffee, coffee, coffee. And a huge sense of humour, because in this space, you add Linux problems to RTAI ones :o) Hum, sorry :o> > > Thanks. > > Wolfgang. > > _______________________________________________ > Rtai-dev mailing list > [EMAIL PROTECTED] > https://mail.gna.org/listinfo/rtai-dev -- Philippe.
