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
Marc CHALAND wrote on 03/06/2008 12:37 PM this:
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 ? If it's the same as the one you send already, no need to.
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 ? No, what I meant was that for the IPC involving the flexpage no UTCB IPC can be used. Any IPC before or after, which qualifies for UTCB IPC will use 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.
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 ?
Strange. How exactly do you set up the worker? Can you send that peace of code? Do you initialize (using dice_server_default_environment) the CORBA_Server_Environment for the worker after the worker thread is started? Regards, Ron. -- Mit freundlichen Gruessen / with regards ra3 @ inf.tu-dresden.de http://os.inf.tu-dresden.de/~ra3/
From Ronald Aigner : Strange. How exactly do you set up the worker? Can you send that peace of code? Do you initialize (using dice_server_default_environment) the CORBA_Server_Environment for the worker after the worker thread is started?
That's it. In fact, server environment was not inited into worker thread but manager thread. That explains why it didn't work. Now it works. Thank you for your great help. Regards Marc
From Adam :
I updated last version of uclibc. It seems that bcmp, bcopy and bzero disapeared, isn't it ? Yep, considered obsolete, so I just let it be this way. Replace with memcpy, memmove, memset (note the reversed arguement for memmove..).
That was just to confirm that change is voluntary :). Is there something like newsletter which explains big changes into public repository ? An entry into wiki or svn logs ?
Add -lrtc -lc_be_time to libs.
It works. I had to add -luc_c -lrtc -lc_be_time. Thank you for your help. Regards Marc
On Fri Mar 07, 2008 at 11:07:35 +0100, Marc CHALAND wrote:
From Adam :
I updated last version of uclibc. It seems that bcmp, bcopy and bzero disapeared, isn't it ? Yep, considered obsolete, so I just let it be this way. Replace with memcpy, memmove, memset (note the reversed arguement for memmove..).
That was just to confirm that change is voluntary :). Is there something like newsletter which explains big changes into public repository ? An entry into wiki or svn logs ?
We could do the wiki thing, we just have to remember :) Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
On Thu Mar 06, 2008 at 12:37:37 +0100, Marc CHALAND wrote:
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 think Ron meant line 319 and 338.
I updated last version of uclibc. It seems that bcmp, bcopy and bzero disapeared, isn't it ?
Yep, considered obsolete, so I just let it be this way. Replace with memcpy, memmove, memset (note the reversed arguement for memmove..).
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 ?
Add -lrtc -lc_be_time to libs. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
Hello: I pushed this old mail to top and i want to know something about UTCB IPC.
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 ? I am interested in the question above because in the Thread::transfer_msg function as this: 1343 sender_regs->copy_msg (dst_regs); 1344 1345 copy_utcb_to (tag, receiver); It seems every time the utcb ipc will follow the register ipc. Is it right? Cheng Guanghui
On Sat Oct 10, 2009 at 10:51:02 +0800, Guanghui, Cheng wrote:
Hello: I pushed this old mail to top and i want to know something about UTCB IPC.
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 ? I am interested in the question above because in the Thread::transfer_msg function as this: 1343 sender_regs->copy_msg (dst_regs); 1344 1345 copy_utcb_to (tag, receiver); It seems every time the utcb ipc will follow the register ipc. Is it right?
Yes, actually there's no difference. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
participants (4)
-
Adam Lackorzynski -
Guanghui, Cheng -
Marc CHALAND -
Ronald Aigner