ex_regs system call is forzed in the do_ipc process

[Adam Lackorzynski]

Hi,

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 
> l4ertl).
> 	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                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/