This list is intended for discussions about the L4 microkernel family and software running on top of L4. ()

headers Yang Xu | 3 Mar 10:16

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

On Mon Mar 03, 2008 at 10:16:00 +0100, Yang Xu wrote:
> On 2/29/08, Adam Lackorzynski <adam <at> os.inf.tu-dresden.de> wrote:
> >
> >
> > On Fri Feb 29, 2008 at 15:23:01 +0100, Yang Xu wrote:
> > > does anybody know that whether l4 linux now already support smp or not
> > > please?
> >
> > It does.
> 
> 
> So if I download the latest version of L4-linux, I can run it on a
> multiprocessor system, and it can make good use of all the cores , right?

Not currently as the µkernel is not ready yet.

> > As far as I know, linux 2.6.x already supports smp. So I am wondering the
> > > the l4-linux 2.6 supports smp or not. if yes,   it is the linux kernel
> > > distributes the threads across the cores or the ukernel does this?
> >
> > Linux distributes it's thread across it's vCPUs, and your vCPUs are
> > where you put them.
> 
> 
> I don't know whether I understand this correctly. it is the linux that
> distributes the threads to all the cores, not the ukernel.
> 
> Does this mean that the ukernel doesn't realise the existence of the other
> cores?

It does but it won't move threads around itself. Userland (e.g. L4Linux)
is supposed to do that and it does so as usual.

Adam
--

-- 
Adam                 adam <at> os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/

hi all,

i have a mysterious double fault error while booting fiasco in qemu.
the problem is that the same configuration works on a native 586 fiasco
and in fiasco-ux without any problems. only with qemu a double fault is 
detected.

i tested it with qemu 0.9.0 and qemu 0.9.1. with version 0.9.0 the boot 
process hangs, without any error messages. with qemu 0.9.1 fiasco says 
that a double fault was detected.

in my configuration i boot two instances of l4linux. while the 
intialization of the
l4linux kernel, fiasco produces the following output:
DOUBLE FAULT!
EAX=c02407d0  ESI=c0240000  DS=0023
EBX=c0401000  EDI=00000000  ES=0023
ECX=3fe19000  EBP=c02406b4  GS=0043
EDX=00000000  ESP=c04017cc  SS=0010   ESP0=c0240800
EFL=00200087  EIP=f002ef06  CS=0008

this happens always after the "l4lx    | Got 0 out of 65536 I/O ports" 
message. but the really
confusing thing is, that sometimes also qemu can boot without any double 
fault.

any ideas whats going wrong here?

thanks
alex

Hi Alex,

can you please try to disable in the Fiasco configuration the option 
"Assembler IPC shortcut". There is currently an unsolved issue.

This could/should solve the problem for time being,

Alex B.

Alexander Arlt wrote:
> hi all,
> 
> i have a mysterious double fault error while booting fiasco in qemu.
> the problem is that the same configuration works on a native 586 fiasco
> and in fiasco-ux without any problems. only with qemu a double fault is 
> detected.
> 
> i tested it with qemu 0.9.0 and qemu 0.9.1. with version 0.9.0 the boot 
> process hangs, without any error messages. with qemu 0.9.1 fiasco says 
> that a double fault was detected.
> 
> in my configuration i boot two instances of l4linux. while the 
> intialization of the
> l4linux kernel, fiasco produces the following output:
> DOUBLE FAULT!
> EAX=c02407d0  ESI=c0240000  DS=0023
> EBX=c0401000  EDI=00000000  ES=0023
> ECX=3fe19000  EBP=c02406b4  GS=0043
> EDX=00000000  ESP=c04017cc  SS=0010   ESP0=c0240800
> EFL=00200087  EIP=f002ef06  CS=0008
> 
> this happens always after the "l4lx    | Got 0 out of 65536 I/O ports" 
> message. but the really
> confusing thing is, that sometimes also qemu can boot without any double 
> fault.
> 
> any ideas whats going wrong here?
> 
> thanks
> alex
> 
> 
> _______________________________________________
> l4-hackers mailing list
> l4-hackers <at> os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
--

-- 
boettcher <at> os.inf.tu-dresden.de
key finger print: 5E79 31F6 F571 5FBA CF75  33FB AA34 4AF4 A633 25B3

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

On Tue Mar 04, 2008 at 11:45:21 +0100, Yang Xu wrote:
> ok I see.... thanks.
> so if we run a RTOS above the ukernel, the RTOS should have the ability to
> distribute the threads.
> ukernel only offers the most basic services: address mapping, IPC, naming
> and so on.

Yes, exactly.

> On 3/3/08, Adam Lackorzynski <adam <at> os.inf.tu-dresden.de> wrote:
> >
> >
> > On Mon Mar 03, 2008 at 10:16:00 +0100, Yang Xu wrote:
> > > On 2/29/08, Adam Lackorzynski <adam <at> os.inf.tu-dresden.de> wrote:
> > > >
> > > >
> > > > On Fri Feb 29, 2008 at 15:23:01 +0100, Yang Xu wrote:
> > > > > does anybody know that whether l4 linux now already support smp or
> > not
> > > > > please?
> > > >
> > > > It does.
> > >
> > >
> > > So if I download the latest version of L4-linux, I can run it on a
> > > multiprocessor system, and it can make good use of all the cores ,
> > right?
> >
> > Not currently as the µkernel is not ready yet.
> >
> > > > As far as I know, linux 2.6.x already supports smp. So I am wondering
> > the
> > > > > the l4-linux 2.6 supports smp or not. if yes,   it is the linux
> > kernel
> > > > > distributes the threads across the cores or the ukernel does this?
> > > >
> > > > Linux distributes it's thread across it's vCPUs, and your vCPUs are
> > > > where you put them.
> > >
> > >
> > > I don't know whether I understand this correctly. it is the linux that
> > > distributes the threads to all the cores, not the ukernel.
> > >
> > > Does this mean that the ukernel doesn't realise the existence of the
> > other
> > > cores?
> >
> > It does but it won't move threads around itself. Userland (e.g. L4Linux)
> > is supposed to do that and it does so as usual.
> >
> >
> >
> > Adam
> > --
> > Adam                 adam <at> os.inf.tu-dresden.de
> > Lackorzynski         http://os.inf.tu-dresden.de/~adam/
> >
> > _______________________________________________
> > l4-hackers mailing list
> > l4-hackers <at> os.inf.tu-dresden.de
> > http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
> >

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

Adam
--

-- 
Adam                 adam <at> os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/

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

Hi,

I am back with my problem with UTCB IPC. To sum up the context :
I use pure l4env applications. Here is the scenario between my server
and my client :
1. client makes an UTCB IPC to manager. Manager does an
l4rm_area_reserve, creates a rcv_fpage, creates worker and sends back
worker thread id to client.
2. client allocates memory and associated flexpage and sends it to server.
3. UTCB IPC is sent to worker with 3 parameters :
  - on client side : utcb->values=0xbff00200: arg1=0x2 arg2=0x1 arg3=0x6
  - on server side : utcb->values=0xbff00200: arg1=0x241401 arg2=0x0
arg3=0x7069776c
It seems that 0xbff00200 is not mapped on the same memory on client
and server side. As there is no problem for first IPC (utcb->values is
also 0xbff00200), is there any potential problem with flexpage ?

As utcb->values is still the same, what happens if several threads try
to make UTCB IPC ?

Another question : when I link my application with liblogserver.a, I
have strange logs :
.rm.sem.mainMain function returned.
It seems that .rm .sem and .main are added by l4env, but I didn't find where.

Regards
Marc

Hi Marc,

Marc CHALAND wrote on 03/06/2008 10:28 AM this:
> Hi,
> 
> I am back with my problem with UTCB IPC. To sum up the context :
> I use pure l4env applications. Here is the scenario between my server
> and my client :
> 1. client makes an UTCB IPC to manager. Manager does an
> l4rm_area_reserve, creates a rcv_fpage, creates worker and sends back
> worker thread id to client.
> 2. client allocates memory and associated flexpage and sends it to server.
> 3. UTCB IPC is sent to worker with 3 parameters :
>   - on client side : utcb->values=0xbff00200: arg1=0x2 arg2=0x1 arg3=0x6
>   - on server side : utcb->values=0xbff00200: arg1=0x241401 arg2=0x0
> arg3=0x7069776c
This should not happend, because sending a flexpage with UTCB is 
currently not supported by Fiasco. Can you post the signature of this 
method, so I can debug the code generation?

> It seems that 0xbff00200 is not mapped on the same memory on client
> and server side.
Right, because UTCBs are unique for each thread, each thread has its own 
UTCB at a different virtual address. However, the same local threads in 
different address spaces--for instance, thread 8.2 and 9.2-- *may* have 
their UTCB mapped to the same virtual address.

> As there is no problem for first IPC (utcb->values is
> also 0xbff00200), is there any potential problem with flexpage ?
UTCB values stays the same. It depends on the generated stub whether 
UTCB IPC is actually used or not. Sending a flexpage, usually 
disqualifies the usage of UTCB IPC.

BTW: Using the same CORBA_Environment for different threads will have 
the effect that a wrong UTCB is used. The generated stub will access the 
UTCB stored in the environment. The actual IPC will use the UTCB of the 
thread sending the IPC. It is therefore important to initialize the 
environment in the thread that is using it.

> 
> As utcb->values is still the same, what happens if several threads try
> to make UTCB IPC ?
A UTCB is unique for each L4 thread, i.e., each thread has it's own UTCB.

> 
> Another question : when I link my application with liblogserver.a, I
> have strange logs :
> .rm.sem.mainMain function returned.
> It seems that .rm .sem and .main are added by l4env, but I didn't find where.
If you are linking with liblogserver.a you should have a log server running.

These suffixes are registered at names (and the kernel debugger) to ease 
debugging.
rm: l4/pkg/l4env/lib/src/startup.c: 316
main: l4/pkg/l4env/lib/src/startup.c: 322
sem: l4/pkg/semaphore/lib/src/semaphore.c: 501

Regards, Ron.

--

-- 
Mit freundlichen Gruessen / with regards
ra3 @ inf.tu-dresden.de
http://os.inf.tu-dresden.de/~ra3/

>From Ronald Aigner :
> > 1. client makes an UTCB IPC to manager. Manager does an
> > l4rm_area_reserve, creates a rcv_fpage, creates worker and sends back
> > worker thread id to client.
> > 2. client allocates memory and associated flexpage and sends it to server.
> > 3. UTCB IPC is sent to worker with 3 parameters :
> >   - on client side : utcb->values=0xbff00200: arg1=0x2 arg2=0x1 arg3=0x6
> >   - on server side : utcb->values=0xbff00200: arg1=0x241401 arg2=0x0
> > arg3=0x7069776c
> This should not happend, because sending a flexpage with UTCB is
> currently not supported by Fiasco. Can you post the signature of this
> method, so I can debug the code generation?

Yes, step 2 is not a UTCB IPC. However 1 and 3 are UTCB IPC.
What do you mean signature ? The full idl file and generated ones ?

> > As there is no problem for first IPC (utcb->values is
> > also 0xbff00200), is there any potential problem with flexpage ?
> UTCB values stays the same. It depends on the generated stub whether
> UTCB IPC is actually used or not. Sending a flexpage, usually
> disqualifies the usage of UTCB IPC.

Do you mean, once a flexpage is sent no UTCB IPC should be sent after ?

> BTW: Using the same CORBA_Environment for different threads will have
> the effect that a wrong UTCB is used. The generated stub will access the
> UTCB stored in the environment. The actual IPC will use the UTCB of the
> thread sending the IPC. It is therefore important to initialize the
> environment in the thread that is using it.

On client side, there is only one thread. One different
CORBA_Environment is used for each call. On server side, One
CORBA_Server_Environment different is used for manager and worker.

> > As utcb->values is still the same, what happens if several threads try
> > to make UTCB IPC ?
> A UTCB is unique for each L4 thread, i.e., each thread has it's own UTCB.

So why is it the same value (0xbff00200) for manager and worker ?

> > It seems that .rm .sem and .main are added by l4env, but I didn't find where.
> If you are linking with liblogserver.a you should have a log server running.

Yes

> These suffixes are registered at names (and the kernel debugger) to ease
> debugging.
> rm: l4/pkg/l4env/lib/src/startup.c: 316
> main: l4/pkg/l4env/lib/src/startup.c: 322

These lines doesn't match my startup.c. I use r315 of public repository.

I updated last version of uclibc. It seems that bcmp, bcopy and bzero
disapeared, isn't it ?
I cannot link my applications :
/home/chaland/l4/build-tudos-ia32/lib/x86_586/libuc_c.a(tzset.o): In
function `tzset':
/home/chaland/l4/build-tudos-ia32/pkg/uclibc/lib/uclibc/ARCH-all/libc/misc/time/time.c:1876:
undefined reference to `time'
Any idea to solve this ?

Regards
Marc

10	February 2012
24	January 2012
23	December 2011
42	November 2011
60	October 2011
46	September 2011
39	August 2011
44	July 2011
52	June 2011
45	May 2011
31	April 2011
47	March 2011
71	February 2011
61	January 2011
21	December 2010
66	November 2010
6	October 2010
16	September 2010
28	August 2010
1	July 2010
10	June 2010
15	May 2010
30	April 2010
14	March 2010
15	February 2010
26	January 2010
20	December 2009
16	November 2009
25	October 2009
18	September 2009
27	August 2009
29	July 2009
21	June 2009
15	May 2009
96	April 2009
84	March 2009
49	February 2009
24	January 2009
25	December 2008
29	November 2008
66	October 2008
19	September 2008
13	August 2008
20	July 2008
35	June 2008
49	May 2008
37	April 2008
74	March 2008
17	February 2008
99	January 2008
17	December 2007
34	November 2007
39	October 2007
110	September 2007
79	August 2007
123	July 2007
73	June 2007
79	May 2007
52	April 2007
60	March 2007
29	February 2007
47	January 2007
80	December 2006
63	November 2006
49	October 2006
38	September 2006
113	August 2006
35	July 2006
68	June 2006
75	May 2006
39	April 2006
44	March 2006
20	February 2006
52	January 2006
27	December 2005
54	November 2005
70	October 2005
77	September 2005
74	August 2005
114	July 2005
182	June 2005
76	May 2005
26	April 2005
83	March 2005
105	February 2005
24	January 2005
13	December 2004
18	November 2004
27	October 2004
38	September 2004
8	August 2004
6	July 2004
10	June 2004
11	May 2004
1	March 2004
10	February 2004
27	January 2004

Re: does l4 linux now support smp?

Re: does l4 linux now support smp?

mysterious double fault

Re: mysterious double fault

Re: does l4 linux now support smp?

Re: does l4 linux now support smp?

need some help in okl4

Back to UTCB IPC

Re: Back to UTCB IPC

Re: Back to UTCB IPC

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31