On Sun, 2007-04-15 at 10:48 -0600, Terry Laurenzo wrote: > Philippe Gerum wrote: > > On Sat, 2007-04-14 at 17:29 -0600, Terry Laurenzo wrote: > > > > > Philippe, > > > Thanks for looking into this, but I discovered that it was a false > > > alarm due to some juvenile broken code on my end. There must be some > > > subtle difference between old->new ipipe/kernel that was causing this > > > to not blow up on the old, but the problem was mine I believe. > > > > > > In my main() function I had a piece of debugging code just before a > > > pause() call after everything was inited. The debugging code sat in > > > an infinite loop displaying some basic stats every 2 seconds. At some > > > point I had commented out the contents of the for(;;) loop but not the > > > loop itself, so that instead of hitting pause() the main() function > > > was just infinite looping (I hardly ever look at the file containing > > > main()). Even though this thread was not supposed to be in a rt > > > context, it did a lot of rt initialization and must have been > > > temporarily switched to a rt context so that the infinite loop was > > > running at a higher priority than the linux domain. > > > > > > I think there is still some weirdness going on here but fixing my code > > > to not be stupid solved the immediate problem. In addition, printing > > > to the console prior to the infinite loop seems to pull the main() > > > thread back into Linux-land and everything works correctly then. > > > > > > > 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? -- Philippe. _______________________________________________ Uclinux-dist-devel mailing list [EMAIL PROTECTED] http://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
