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 -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~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. -- Sirrix AG security technologies - http://www.sirrix.com Oskar Senft eMail: o.senft@sirrix.com Tel +49 (681) 936 251 - 119 Fax +49 (681) 936 251 - 500 get public key from keyserver Fingerprint 6FC6 3E44 233F 7F4B 33C7 A8D0 2EDA F3BA B5A3 0BA4 This message may contain confidential and/or privileged information. If you are not the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.
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 -- ## Dept. of Computer Science, Dresden University of Technology, Germany ## ## http://os.inf.tu-dresden.de/~fm3 ##
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. -- Sirrix AG security technologies - http://www.sirrix.com Oskar Senft eMail: o.senft@sirrix.com Tel +49 (681) 936 251 - 119 Fax +49 (681) 936 251 - 500 get public key from keyserver Fingerprint 6FC6 3E44 233F 7F4B 33C7 A8D0 2EDA F3BA B5A3 0BA4 This message may contain confidential and/or privileged information. If you are not the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.
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
-- Sirrix AG security technologies - http://www.sirrix.com Oskar Senft eMail: o.senft@sirrix.com Tel +49 (681) 936 251 - 119 Fax +49 (681) 936 251 - 500 get public key from keyserver Fingerprint 6FC6 3E44 233F 7F4B 33C7 A8D0 2EDA F3BA B5A3 0BA4 This message may contain confidential and/or privileged information. If you are not the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.
participants (5)
-
Adam Lackorzynski -
Frank Mehnert -
Oskar Senft -
Oskar Senft -
Rene Reusner