ex_regs system call is forzed in the do_ipc process
Hello: When i use the ex_regs system call to trigger the exception ipc it seems to be frozed in the do_ipc stange. I use jdb to debug this current thread lists is like this: 9.04 l4ertl.exceptio 10 9.03 rcv,ipc_progr 9.03 l4ertl.timer0 10 9.02 rcv,ipc_progr 9.02 domain2.main 10 9.04 rcv,ipc_progr,exc_progr l4ertl.exceptio is the pager of domain2.main. And now l4ertl.timer0 is executing ex_regs system to trigger exception for domain2.main. l4ertl.exceptio is waiting for the exception ipc from the l4ertl2.main2. In detail l4ertl.exceptio is in ipc (user level registers). l4ertl.timer0 is in ipc (user level registers), too. domain2.main is in the exception 255. It seems to be dead lock in the kernel. Very strange. Thanks. Cheng Guanghui
Hi, On Tue Oct 20, 2009 at 16:20:03 +0800, Guanghui, Cheng wrote:
When i use the ex_regs system call to trigger the exception ipc it seems to be frozed in the do_ipc stange. I use jdb to debug this current thread lists is like this:
9.04 l4ertl.exceptio 10 9.03 rcv,ipc_progr 9.03 l4ertl.timer0 10 9.02 rcv,ipc_progr 9.02 domain2.main 10 9.04 rcv,ipc_progr,exc_progr
l4ertl.exceptio is the pager of domain2.main. And now l4ertl.timer0 is executing ex_regs system to trigger exception for domain2.main. l4ertl.exceptio is waiting for the exception ipc from the l4ertl2.main2. In detail l4ertl.exceptio is in ipc (user level registers). l4ertl.timer0 is in ipc (user level registers), too. domain2.main is in the exception 255. It seems to be dead lock in the kernel. Very strange.
I think that's what the L4_THREAD_EX_REGS_NO_CANCEL flag is about. 'cancel' here means that a possibly ongoing IPC is being canceled, i.e. aborted. When you remove the flag, the IPCs will be aborted and return. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
On Wednesday 21 October 2009 00:44:34 Adam Lackorzynski wrote:
Hi,
On Tue Oct 20, 2009 at 16:20:03 +0800, Guanghui, Cheng wrote:
When i use the ex_regs system call to trigger the exception ipc it seems to be frozed in the do_ipc stange. I use jdb to debug this current thread lists is like this:
9.04 l4ertl.exceptio 10 9.03 rcv,ipc_progr 9.03 l4ertl.timer0 10 9.02 rcv,ipc_progr 9.02 domain2.main 10 9.04 rcv,ipc_progr,exc_progr
l4ertl.exceptio is the pager of domain2.main. And now l4ertl.timer0 is executing ex_regs system to trigger exception for domain2.main. l4ertl.exceptio is waiting for the exception ipc from the l4ertl2.main2. In detail l4ertl.exceptio is in ipc (user level registers). l4ertl.timer0 is in ipc (user level registers), too. domain2.main is in the exception 255. It seems to be dead lock in the kernel. Very strange.
I think that's what the L4_THREAD_EX_REGS_NO_CANCEL flag is about. 'cancel' here means that a possibly ongoing IPC is being canceled, i.e. aborted. When you remove the flag, the IPCs will be aborted and return. It can't work either. I tested my demo many times and found: If the thread in which the exception ipc will be triggered is only 1 L4 thread or is 1 L4eRTL thread (You know in my design there are many L4eRTL threads in the L4 main thread), the exception ipc could be triggered correctly. But i don't test two l4ertl threads because only one can't work. 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. Thanks. Cheng Guanghui
On Wed Oct 21, 2009 at 15:25:51 +0800, Guanghui, Cheng wrote:
On Wednesday 21 October 2009 00:44:34 Adam Lackorzynski wrote:
Hi,
On Tue Oct 20, 2009 at 16:20:03 +0800, Guanghui, Cheng wrote:
When i use the ex_regs system call to trigger the exception ipc it seems to be frozed in the do_ipc stange. I use jdb to debug this current thread lists is like this:
9.04 l4ertl.exceptio 10 9.03 rcv,ipc_progr 9.03 l4ertl.timer0 10 9.02 rcv,ipc_progr 9.02 domain2.main 10 9.04 rcv,ipc_progr,exc_progr
l4ertl.exceptio is the pager of domain2.main. And now l4ertl.timer0 is executing ex_regs system to trigger exception for domain2.main. l4ertl.exceptio is waiting for the exception ipc from the l4ertl2.main2. In detail l4ertl.exceptio is in ipc (user level registers). l4ertl.timer0 is in ipc (user level registers), too. domain2.main is in the exception 255. It seems to be dead lock in the kernel. Very strange.
I think that's what the L4_THREAD_EX_REGS_NO_CANCEL flag is about. 'cancel' here means that a possibly ongoing IPC is being canceled, i.e. aborted. When you remove the flag, the IPCs will be aborted and return. It can't work either. I tested my demo many times and found: If the thread in which the exception ipc will be triggered is only 1 L4 thread or is 1 L4eRTL thread (You know in my design there are many L4eRTL threads in the L4 main thread), the exception ipc could be triggered correctly. But i don't test two l4ertl threads because only one can't work. 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? Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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. 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? Cheers. Thanks. Cheng Guanghui
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@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
participants (2)
-
Adam Lackorzynski -
Guanghui, Cheng