On Sun, 2007-04-15 at 14:28 -0600, Terry Laurenzo wrote:
>
> > > > If the main thread has been explicitely shadowed by a Xenomai task (i.e.
> > > > rt_task_shadow), then it's plausible. Writing to the console would
> > > > switch the thread to secondary mode in order to use regular Linux
> > > > services, and would also allow non real-time device interrupts to flow
> > > > down to the Linux kernel while running the loop.
> > > >
> > > >
> > > >
> > > In this situation, the main thread was *not* shadowed through a call
> > > to rt_task_shadow, yet somehow the main thread was getting some form
> > > of real-time priority and stalling other things. When I get a chance,
> > > I will try to produce a stripped down test case that duplicates the
> > > behavior.
> > >
> >
> > Linux interrupts are threaded when the I-pipe is enabled; any chance the
> > main thread was undergoing the SCHED_FIFO policy with a higher fixed
> > priority than some/all of the regular IRQ threads?
> >
> >
> If I understand you, then I don't see how. Literally, the main thread
> was sitting in a "for(;;) { }" loop. This stalled the rest of the
> system until CTRL-C was pressed. Adding a printf so that the code
> read as follows caused the system to not stall:
> printf("Looping\n");
> for (;;) { }
> Of course, my real fix was to remove the erroneous infinite loop, but
> as I understand it, the system should not have stalled with the loop
> in place.
>
The only way for a syscall (i.e. write(2) in case of printf()) to have
some kind of "relaxing effect" is when the undergoing thread runs as a
Xenomai shadow. Reading /proc/xenomai/sched (in the non-stalling
configuration) would help checking this.
Which skin are you using btw, POSIX or native?
--
Philippe.
_______________________________________________
Uclinux-dist-devel mailing list
Uclinux-dist-devel@blackfin.uclinux.org
http://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
