On 07/19/2004 06:51 PM Philippe Gerum wrote: > 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>
Well, I was afraid of that ;-). >> 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. Lightweight switch? As I see it, it's almost a normal switch_to() as called from Linux's schedule(), apart from restoring the MMU context and saving/restoring the interrupt flag. > 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. This makes things clearer and I think there is a problem with trap handling, as already mentioned in another email. > > 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> Well, often too much coffee == trail and error without thinking. Thanks for your valuable input. Wolfgang.
