ex_regs system call is forzed in the do_ipc process
adam at os.inf.tu-dresden.de
Fri Oct 23 11:13:14 CEST 2009
On Thu Oct 22, 2009 at 21:26:13 +0800, Guanghui, Cheng wrote:
> > If i ajust the exception handler when the L4 thread is runnning in the
> > > L4 thread but i try to trigger the exception ipc when the main thread is
> > > running in the L4eRTL thread, the ex_regs system call can't return and it
> > > seems it will be blocked in the kernel whatever i used
> > > "L4_THREAD_EX_REGS_NO_CANCEL" or not. Vice versa.
> > I don't quite get a clear understanding of what's happening from the
> > description but maybe a thread is busy looping. Is some thread ready?
> Now the L4eRTL with using exception ipc triggerred interrupt-handling
> could work. All the demos before i prepared in the RTLWS11 about l4ertl
> could work with this version, about : single l4ertl thread in single doman,
> double l4ertl threads in single domain, multiple l4ertl domains coexisting
> with l4linux. But obviously the booting l4linux is much slower when runnng
> l4ertl app comparing to last l4ertl version (lazy interrupt handling in
> In this place i describe the problem again and hope it could be useful
> for you.
> You know the L4eRTl could support multiple l4ertl threads in one
> l4 thread. But firstly there is one l4 thread responsible for some necessary
> initialization issues such as init_sched, init_time and init_signals which are
> necessary for l4ertl system. And then l4 thread will create a first l4ertl
> main thread which will execute the user space main function. And this l4
> thread will run as the idle thread in the l4ertl system finally.
> If there is a context switch between l4ertl thread to l4ertl idle (l4 thread)
> the ex_regs_flags system call will be frozed.
Hmm, that rather sounds like the l4ertl threads should switch themselves
by changing their stack. But if it works now it's also fine.
> Later i fixed the ugly design and now there is l4ertl idle thread is
> also a l4ertl thread not l4 thread any more. The system could work. I
> reserved all the environments and codes which could cause this frozen.
> Maybe next time i could show you and you could debug it.
> The next step should be the implementation of vtimers. Because
> it is in the user space and i could try different timer source like RTC and
> HPET. Last time you mentioned HPET and i think it should be better than
> RTC because HPET is internal timer and it should be faster than external RTC
> timer. Right?
HPET is probably faster than that, yes. Basically you should be able to
program the HPET in user-space and use this as a timer source.
Adam adam at os.inf.tu-dresden.de
More information about the l4-hackers