On Mon, 2004-07-19 at 20:34, Wolfgang Grandegger wrote: > 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. >
Lightweight in the sense that no Linux switch head or tail code is performed. > > 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. > > _______________________________________________ > Rtai-dev mailing list > [EMAIL PROTECTED] > https://mail.gna.org/listinfo/rtai-dev -- Philippe.
