Hi all!
We are using different Deamons running in L4Linux providing IPC services to other L4 task. With the most current DROPS CVS checkout, the L4Linux user processes freeze completely, as soon as an IPC call is executed which causes the process to sleep (eg. DICE IPC server loop).
The L4Linux kernel seems to run, as it answers Ethernet/IP "ping" requests. A connection to a running SSH daemon no longer is possible and active SSH connection freeze, too. => Only L4Linux userland processes are frozen ?!?
This did not happen with other version of L4Linux (eg. from January) and does not depend on the program we run in L4Linux - it happens with different applications that provide IPC services.
Is this a problem with our settings for L4Env / L4Linux? Or could it be a bug in L4Linux?
Do you have a test program that should run?
Regards Oskar.
On Tue May 02, 2006 at 18:51:39 +0200, Oskar Senft wrote:
We are using different Deamons running in L4Linux providing IPC services to other L4 task. With the most current DROPS CVS checkout, the L4Linux user processes freeze completely, as soon as an IPC call is executed which causes the process to sleep (eg. DICE IPC server loop).
The L4Linux kernel seems to run, as it answers Ethernet/IP "ping" requests. A connection to a running SSH daemon no longer is possible and active SSH connection freeze, too. => Only L4Linux userland processes are frozen ?!?
Sounds like scheduling is blocked.
This did not happen with other version of L4Linux (eg. from January) and does not depend on the program we run in L4Linux - it happens with different applications that provide IPC services.
Is this a problem with our settings for L4Env / L4Linux? Or could it be a bug in L4Linux?
Do you have a test program that should run?
Something as simple as
#include <l4/util/util.h>
int main(void) { while (1) l4_sleep(500);
return 0; }
should work.
Are your user apps in the alien state? (Check with lp in jdb.)
Adam
Hi!
Thank you for your reply!
Something as simple as [...] should work.
Hmm ... your examples work, indeed. Ours (using IPC) does not :-(
#include <l4/sys/ipc.h> #include <stdio.h>
int main(void) { while (1) { l4_threadid_t src; l4_umword_t dword0, dword1; l4_msgdope_t result;
// wait for IPC message until timeout reached if (l4_ipc_wait(&src, L4_IPC_SHORT_MSG, &dword0, &dword1, L4_IPC_TIMEOUT(0, 0, 1, 4, 0, 0), // wait for some time &result)) { dword0 = 0; } printf("%lu\n", dword0); }
return 0; }
Are your user apps in the alien state? (Check with lp in jdb.)
26.00 a *.** 3s rcv,ipc_progr,alien
Seems so ... what does that mean? The above sample always blocks for exactly the IPC wait time. Then it runs again (accepting input, eg. from keyboard) and blocks again. It can be terminated by pressing CTRL-C as the input seems to be queued until the IPC wait timeout expired.
As I previously said, our programs used to run with older DROPS versions ... what happened?
Best regards Oskar.
Hi Oskar,
Hmm ... your examples work, indeed. Ours (using IPC) does not :-(
#include <l4/sys/ipc.h> #include <stdio.h>
int main(void) { while (1) { l4_threadid_t src; l4_umword_t dword0, dword1; l4_msgdope_t result;
// wait for IPC message until timeout reached if (l4_ipc_wait(&src, L4_IPC_SHORT_MSG, &dword0, &dword1, L4_IPC_TIMEOUT(0, 0, 1, 4, 0, 0), // wait for some time &result)) { dword0 = 0; } printf("%lu\n", dword0);}
return 0; }
Are your user apps in the alien state? (Check with lp in jdb.)
26.00 a *.** 3s rcv,ipc_progr,alien
Seems so ... what does that mean?
`Alien' means that this task is special handled by the Fiasco kernel. In contrast to normal behaviour, L4 syscalls executed in the context of an alien task generate exceptions just before and after the L4 syscall. These exceptions allow the L4Linux server to set the internal Linux state of that task to "disk wait" to prevent that task from the Linux scheduling.
The above sample always blocks for exactly the IPC wait time. Then it runs again (accepting input, eg. from keyboard) and blocks again. It can be terminated by pressing CTRL-C as the input seems to be queued until the IPC wait timeout expired.
I cannot check this as I'm currently work with a different branch, but I would expect the exact behaviour as you describe. Or are _all_ Linux applications frozen while this task waits for an incoming IPC?
Frank
Hi Frank!
`Alien' means that this task is special handled by the Fiasco kernel. In contrast to normal behaviour, L4 syscalls executed in the context of an alien task generate exceptions just before and after the L4 syscall. These exceptions allow the L4Linux server to set the internal Linux state of that task to "disk wait" to prevent that task from the Linux scheduling.
Ok, thank you for the explanation. Where could I read more about that?
The above sample always blocks for exactly the IPC wait time. Then it runs again (accepting input, eg. from keyboard) and blocks again. It can be terminated by pressing CTRL-C as the input seems to be queued until the IPC wait timeout expired.
I cannot check this as I'm currently work with a different branch, but I would expect the exact behaviour as you describe. Or are _all_ Linux applications frozen while this task waits for an incoming IPC?
Yes, that is the problem. As I already described, neither switching to another Linux Console (ALT-F2, ...) nor SSH work when the process blocks - so I guess that all other processes (besides of the test and SSHD) are frozen, too. The freezing of the *single* process is a expected - sure.
Regards Oskar.
Hi folks!
As I previously said, our programs used to run with older DROPS versions ... what happened?
So, I made some more tests, all with DROPS / L4Env from yesterday (with Adams patch for "loader").
Test 1) - new DROPS - new FIASCO - new L4Linux Causes IPC problems (as already stated).
Test 2) - new DROPS - new FIASCO - old L4Linux (from January) Linker error: exec | vmlinuz26-l4linux-2.6.15-hddenc: Symbol atexit NOT FOUND
Test 3) - new DROPS - old FIASCO (from January) - new L4Linux This one works!! The problems with IPC disappeared. Anyway, I get a "warning" saying which has to be accepted in JDB by "Go": l4lx | The kernel ABI version is too low: kernel has 4, I need 5
From that, I would state, that there is either a problem in FIASCO
itself or in our configuration of FIASCO.
Regards Oskar.
Hi!
Thank you for your reply!
Something as simple as [...] should work.
Hmm ... your examples work, indeed. Ours (using IPC) does not :-(
#include <l4/sys/ipc.h> #include <stdio.h>
int main(void) { while (1) { l4_threadid_t src; l4_umword_t dword0, dword1; l4_msgdope_t result;
// wait for IPC message until timeout reached if (l4_ipc_wait(&src, L4_IPC_SHORT_MSG, &dword0, &dword1, L4_IPC_TIMEOUT(0, 0, 1, 4, 0, 0), // wait for some time &result)) { dword0 = 0; } printf("%lu\n", dword0); }
return 0; }
Are your user apps in the alien state? (Check with lp in jdb.)
26.00 a *.** 3s rcv,ipc_progr,alien
Seems so ... what does that mean? The above sample always blocks for exactly the IPC wait time. Then it runs again (accepting input, eg. from keyboard) and blocks again. It can be terminated by pressing CTRL-C as the input seems to be queued until the IPC wait timeout expired.
As I previously said, our programs used to run with older DROPS versions ... what happened?
Best regards Oskar.
Oskar Senft(oskar.senft@crypto.rub.de)@2006.05.02 18:51:39 +0200:
Hi all!
We are using different Deamons running in L4Linux providing IPC services to other L4 task. With the most current DROPS CVS checkout, the L4Linux user processes freeze completely, as soon as an IPC call is executed which causes the process to sleep (eg. DICE IPC server loop).
The L4Linux kernel seems to run, as it answers Ethernet/IP "ping" requests. A connection to a running SSH daemon no longer is possible and active SSH connection freeze, too. => Only L4Linux userland processes are frozen ?!?
This did not happen with other version of L4Linux (eg. from January) and does not depend on the program we run in L4Linux - it happens with different applications that provide IPC services.
Mmmh, how old is your fiasco kernel? Can you try your stuff with the current fiasco kernel and an older kernel (with the tag 'before_merge_new_ipc_path').
rene
Is this a problem with our settings for L4Env / L4Linux? Or could it be a bug in L4Linux?
Do you have a test program that should run?
Regards Oskar.
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hi!
Mmmh, how old is your fiasco kernel? Can you try your stuff with the current fiasco kernel and an older kernel (with the tag 'before_merge_new_ipc_path').
I've just sent an example program that does *not* run with the current kernel (yesterday's CVS checkout).
Please take a look at that program.
Regards Oskar.
rene
Is this a problem with our settings for L4Env / L4Linux? Or could it be a bug in L4Linux?
Do you have a test program that should run?
Regards Oskar.
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Frank Mehnert -
Oskar Senft -
Oskar Senft -
Rene Reusner