ex_regs system call is forzed in the do_ipc process

[Guanghui, Cheng]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[Adam Lackorzynski]

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

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[Guanghui, Cheng]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[Adam Lackorzynski]

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

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

[Guanghui, Cheng]

Some parts of this message have been removed. Learn more about Nabble's security policy.

> 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

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

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

_______________________________________________
l4-hackers mailing list
l4-hackers@...
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers