Hi,
I made a svn up into l4linux-2.6, made an oldconfig and encountered some problems with lxevent and... cron (???). Problem with lxevent, was into rmgr_init_ping_call: _dice_msg_buffer was NULL.
So I decided to purge all build directories (fiasco, build dir, install dir and l4linux). I edited a new configuration for l4linux but I encountered a problem : I cannot disable VGA_CONSOLE if I don't use EMBEDDED. So I decided to set it. But, now, I've got some stability problems : I get the following message :
--------------------------------------------------------------------------------------------------------------------------------- KERNEL: set_tls: non-existing thread 003401e1
KERNEL: set_ldt: non-existing task 0. Trap: 13: 0000 [#1] Modules linked in:
Pid: 1070, comm: consolechars Not tainted (2.6.24-l4 #14) EIP: ff7c:[<00405055>] EFLAGS: 00010246 CPU: 0 EIP is at l4x_switch_to+0xd0/0xd3 EAX: 1003cc60 EBX: 00000018 ECX: 00000000 EDX: 00000000 ESI: 003401e1 EDI: 1003ca80 EBP: 1081013c ESP: 108139a0 DS: 0000 ES: 4280 FS: 0023 GS: 0043 SS: 0023 Process consolechars (pid: 1070, ti=10812000 task=1003ca80 task.ti=108d0000) Stack: 108139a8 00000000 1003ca80 10810000 00000400 0054da88 005f0fbc 10810000 00000400 1003ca80 10812000 108139e8 ffff950d 00000400 0000000b 0054dd5b 108139e8 ffff950d 005f67b0 005f67b0 ffff950d 0041923c 10810000 005f5f00 Call Trace: [<0054da88>] schedule+0x171/0x1bb [<0054dd5b>] schedule_timeout+0x7b/0x99 [<0041923c>] process_timeout+0x0/0x9 [<0045672f>] do_select+0x397/0x3ee [<00456d5f>] __pollwait+0x0/0xaf [<0040eeff>] default_wake_function+0x0/0x14 [<0049f877>] __make_request+0x472/0x4a8 [<0040e891>] update_curr+0x52/0xc8 [<0040eb9b>] dequeue_entity+0xb/0x2a [<0040fbbf>] dequeue_task_fair+0x1b/0x2f [<0040f644>] finish_task_switch+0x1f/0x50 [<0054dab4>] schedule+0x19d/0x1bb [<0054dcca>] io_schedule+0xb/0x12 [<00467424>] sync_buffer+0x3b/0x40 [<0054debd>] __wait_on_bit+0x53/0x5c [<004673e9>] sync_buffer+0x0/0x40 [<004673e9>] sync_buffer+0x0/0x40 [<0054df28>] out_of_line_wait_on_bit+0x62/0x6a [<00421d9c>] wake_bit_function+0x0/0x34 [<004820b3>] __ext3_get_inode_loc+0x29e/0x2f6 [<00448a95>] kmem_cache_alloc+0x66/0x9e [<0045a1da>] __d_lookup+0x97/0xd5 [<0045a1da>] __d_lookup+0x97/0xd5 [<00451dd2>] do_lookup+0x59/0x16b [<00453837>] __link_path_walk+0x930/0xa72 [<0045a6a3>] dput+0x2a/0xe5 [<00453837>] __link_path_walk+0x930/0xa72 [<0045d5ea>] mntput_no_expire+0x1c/0x5c [<0045697e>] core_sys_select+0x1f8/0x2ae [<00454514>] __user_walk_fd+0x43/0x4c [<00449151>] kmem_cache_free+0x40/0x93 [<00452d6f>] getname+0x68/0xa2 [<0044e26d>] cp_new_stat64+0xff/0x111 [<00456eb3>] sys_select+0xa5/0x173 [<0040401b>] l4x_user_dispatcher+0x8e2/0x184c [<0040c030>] _upage_start+0x30/0x890 [<00456e0e>] sys_select+0x0/0x173 [<0044fd40>] do_execve+0x172/0x17b [<0044fd40>] do_execve+0x172/0x17b [<005c4372>] kernel_init+0x0/0x254 [<004079a3>] l4_kernelinternal_execve+0xc2/0xc9 [<00400915>] in_kernel_int80_helper+0x9/0x17 [<005c4372>] kernel_init+0x0/0x254 [<004094a3>] kernel_execve+0x17/0x1a [<00400198>] run_init_process+0x20/0x24 [<00400242>] init_post+0xa6/0xd0 [<005c45bc>] kernel_init+0x24a/0x254 [<0040f644>] finish_task_switch+0x1f/0x50 [<005c4372>] kernel_init+0x0/0x254 [<005c4372>] kernel_init+0x0/0x254 [<004072cb>] kernel_thread_start+0x28/0x2d [<00406ed2>] sys_enosys+0x0/0x6 ======================= Code: 00 00 89 04 d5 04 e0 5a 00 89 0c d5 00 e0 5a 00 8b b7 00 02 00 00 8d 87 e0 01 00 00 bb 18 00 00 00 31 c9 89 ca 0f 00 d0 5b 5e 5f <c3> 90 90 57 56 83 ec 04 8b 74 24 10 8b 7c 24 14 f6 46 0d 20 74 EIP: [<00405055>] l4x_switch_to+0xd0/0xd3 SS:ESP 0023:108139a0 ---[ end trace 10d172b22dcd8354 ]--- Fixing recursive fault but reboot is needed! ------------------------------------------------------------------------------------------------------------------------
I thought I forgot to set an option into kernel. But this happens sometimes on egrep, which, etc.. Any idea on the problem ? Regards Marc
Salut Marc,
On Wed Feb 20, 2008 at 19:01:25 +0100, Marc CHALAND wrote:
I made a svn up into l4linux-2.6, made an oldconfig and encountered some problems with lxevent and... cron (???). Problem with lxevent, was into rmgr_init_ping_call: _dice_msg_buffer was NULL.
So I decided to purge all build directories (fiasco, build dir, install dir and l4linux). I edited a new configuration for l4linux but I encountered a problem : I cannot disable VGA_CONSOLE if I don't use EMBEDDED.
Yes, that's Linux trying to prevent you from doing stupid things :)
So I decided to set it. But, now, I've got some stability problems : I get the following message :
I think it has nothing to do with CONFIG_EMBEDDED.
KERNEL: set_tls: non-existing thread 003401e1
KERNEL: set_ldt: non-existing task 0. Trap: 13: 0000 [#1] Modules linked in:
Pid: 1070, comm: consolechars Not tainted (2.6.24-l4 #14) EIP: ff7c:[<00405055>] EFLAGS: 00010246 CPU: 0 EIP is at l4x_switch_to+0xd0/0xd3 EAX: 1003cc60 EBX: 00000018 ECX: 00000000 EDX: 00000000 ESI: 003401e1 EDI: 1003ca80 EBP: 1081013c ESP: 108139a0 DS: 0000 ES: 4280 FS: 0023 GS: 0043 SS: 0023 Process consolechars (pid: 1070, ti=10812000 task=1003ca80 task.ti=108d0000) Stack: 108139a8 00000000 1003ca80 10810000 00000400 0054da88 005f0fbc 10810000 00000400 1003ca80 10812000 108139e8 ffff950d 00000400 0000000b 0054dd5b 108139e8 ffff950d 005f67b0 005f67b0 ffff950d 0041923c 10810000 005f5f00 Call Trace: [<0054da88>] schedule+0x171/0x1bb [<0054dd5b>] schedule_timeout+0x7b/0x99 [<0041923c>] process_timeout+0x0/0x9 [<0045672f>] do_select+0x397/0x3ee [<00456d5f>] __pollwait+0x0/0xaf [<0040eeff>] default_wake_function+0x0/0x14 [<0049f877>] __make_request+0x472/0x4a8 [<0040e891>] update_curr+0x52/0xc8 [<0040eb9b>] dequeue_entity+0xb/0x2a [<0040fbbf>] dequeue_task_fair+0x1b/0x2f [<0040f644>] finish_task_switch+0x1f/0x50 [<0054dab4>] schedule+0x19d/0x1bb [<0054dcca>] io_schedule+0xb/0x12 [<00467424>] sync_buffer+0x3b/0x40 [<0054debd>] __wait_on_bit+0x53/0x5c [<004673e9>] sync_buffer+0x0/0x40 [<004673e9>] sync_buffer+0x0/0x40 [<0054df28>] out_of_line_wait_on_bit+0x62/0x6a [<00421d9c>] wake_bit_function+0x0/0x34 [<004820b3>] __ext3_get_inode_loc+0x29e/0x2f6 [<00448a95>] kmem_cache_alloc+0x66/0x9e [<0045a1da>] __d_lookup+0x97/0xd5 [<0045a1da>] __d_lookup+0x97/0xd5 [<00451dd2>] do_lookup+0x59/0x16b [<00453837>] __link_path_walk+0x930/0xa72 [<0045a6a3>] dput+0x2a/0xe5 [<00453837>] __link_path_walk+0x930/0xa72 [<0045d5ea>] mntput_no_expire+0x1c/0x5c [<0045697e>] core_sys_select+0x1f8/0x2ae [<00454514>] __user_walk_fd+0x43/0x4c [<00449151>] kmem_cache_free+0x40/0x93 [<00452d6f>] getname+0x68/0xa2 [<0044e26d>] cp_new_stat64+0xff/0x111 [<00456eb3>] sys_select+0xa5/0x173 [<0040401b>] l4x_user_dispatcher+0x8e2/0x184c [<0040c030>] _upage_start+0x30/0x890 [<00456e0e>] sys_select+0x0/0x173 [<0044fd40>] do_execve+0x172/0x17b [<0044fd40>] do_execve+0x172/0x17b [<005c4372>] kernel_init+0x0/0x254 [<004079a3>] l4_kernelinternal_execve+0xc2/0xc9 [<00400915>] in_kernel_int80_helper+0x9/0x17 [<005c4372>] kernel_init+0x0/0x254 [<004094a3>] kernel_execve+0x17/0x1a [<00400198>] run_init_process+0x20/0x24 [<00400242>] init_post+0xa6/0xd0 [<005c45bc>] kernel_init+0x24a/0x254 [<0040f644>] finish_task_switch+0x1f/0x50 [<005c4372>] kernel_init+0x0/0x254 [<005c4372>] kernel_init+0x0/0x254 [<004072cb>] kernel_thread_start+0x28/0x2d [<00406ed2>] sys_enosys+0x0/0x6 ======================= Code: 00 00 89 04 d5 04 e0 5a 00 89 0c d5 00 e0 5a 00 8b b7 00 02 00 00 8d 87 e0 01 00 00 bb 18 00 00 00 31 c9 89 ca 0f 00 d0 5b 5e 5f <c3> 90 90 57 56 83 ec 04 8b 74 24 10 8b 7c 24 14 f6 46 0d 20 74 EIP: [<00405055>] l4x_switch_to+0xd0/0xd3 SS:ESP 0023:108139a0 ---[ end trace 10d172b22dcd8354 ]--- Fixing recursive fault but reboot is needed!
I thought I forgot to set an option into kernel. But this happens sometimes on egrep, which, etc.. Any idea on the problem ?
The fault is on the ret of l4x_switch_to which somehow looks like a corrupt stack. Also there are errors from the load_TLS call which is also strange. With 'sometimes', do you mean it's hard to trigger or rather that it doesn't matter which program you use? Just for completeness, did you upgrade your Linux distribution you're running inside L4Linux? Or any other change? If you comment in the LOG_printf in l4x_switch_to (arch/l4/kernel/arch-i386/dispatch.c), do it work ok or is there something strange (e.g. sane PIDs, etc.)?
Adam
Sorry Adam, I think I have trouble with my ISP. I didn't get your mail.
From Adam Lackorzynski
I think it has nothing to do with CONFIG_EMBEDDED.
Thank you for this info. So you confirm, to build l4linux with L4con, EMBEDDED should be set on version 2.6.24 ?
With 'sometimes', do you mean it's hard to trigger or rather that it doesn't matter which program you use?
It's easy to trigger (during init). But never at the same moment.
Just for completeness, did you upgrade your Linux distribution you're running inside L4Linux? Or any other change?
I don't remember exactly why, but I had to upgrade generic_dm or dm_phys so that I had to upgrade all TUDOS pkg directory and l4linux. I have another strange behavior with dice : one of my IDL doesn't work with last version of DICE. I had to go back to 238 revision of dice to work. Code generated is very strange :
-----------> IDL : int socket([in] int domain, [in] int type, [in] int protocol, [out] l4_threadid_t *socket_worker, [out] int *serrno);
-------------> last revision of dice on client side : int lwip_sockmanager_socket_call (const_CORBA_Object _dice_corba_obj, int domain /* in */, int type /* in */, int protocol /* in */, l4_threadid_t *socket_worker /* out */, int *serrno /* out */, CORBA_Environment *_dice_corba_env) { /* size = 20 bytes == 5 dwords */ typedef union { struct { long _dice_opcode; int domain; int type; int protocol; } sockmanager_socket_in; struct { l4_umword_t _exception; l4_threadid_t socket_worker; int serrno; int _dice_return; } sockmanager_socket_out; struct { l4_fpage_t _dice_rcv_fpage; l4_msgdope_t _dice_size_dope; l4_msgdope_t _dice_send_dope; l4_umword_t _word[2]; } _word; } lwip_sockmanager_sockmanager_socket_msg_buffer_t; int _dice_return = 0; lwip_sockmanager_sockmanager_socket_msg_buffer_t *_dice_msg_buffer = (lwip_sockmanager_sockmanager_socket_msg_buffer_t*)_dice_corba_env->utcb->values; l4_umword_t _exception __attribute__ ((unused)); l4_msgtag_t tag_dummy __attribute__ ((unused)) = l4_msgtag(0,0,0,0); l4_msgdope_t _dice_result = { raw: 0 }; _dice_msg_buffer->_word._dice_size_dope = L4_IPC_DOPE( sizeof(*_dice_msg_buffer)/sizeof(long)-3, 0); _dice_msg_buffer->sockmanager_socket_in._dice_opcode = LWIP_SOCKMANAGER_SOCKET_OPCODE; _dice_msg_buffer->sockmanager_socket_in.domain = domain; _dice_msg_buffer->sockmanager_socket_in.type = type; _dice_msg_buffer->sockmanager_socket_in.protocol = protocol; do { l4_ipc_call_tag(*_dice_corba_obj, L4_IPC_SHORT_MSG, LWIP_SOCKMANAGER_SOCKET_OPCODE, domain, l4_msgtag(0, 4, 0, 0), /* utcb */ L4_IPC_SHORT_MSG, &_dice_msg_buffer->sockmanager_socket_out._exception, (l4_umword_t*)socket_worker, _dice_corba_env->timeout, &_dice_result, &tag_dummy); } while ((L4_IPC_ERROR(_dice_result) == L4_IPC_SEABORTED) || (L4_IPC_ERROR(_dice_result) == L4_IPC_SECANCELED)); if (DICE_EXPECT_FALSE(L4_IPC_ERROR(_dice_result))) { CORBA_exception_set(_dice_corba_env, CORBA_SYSTEM_EXCEPTION, CORBA_DICE_EXCEPTION_IPC_ERROR, 0); DICE_IPC_ERROR(_dice_corba_env) = L4_IPC_ERROR(_dice_result); return _dice_return; } if (DICE_EXPECT_FALSE(_dice_msg_buffer->sockmanager_socket_out._exception != 0)) { DICE_EXCEPTION_MAJOR(_dice_corba_env) = ((dice_CORBA_exception_type){ _raw: _dice_msg_buffer->sockmanager_socket_out._exception})._corba.major; DICE_EXCEPTION_MINOR(_dice_corba_env) = ((dice_CORBA_exception_type){ _raw: _dice_msg_buffer->sockmanager_socket_out._exception})._corba.repos_id; return _dice_return; } (*socket_worker) = _dice_msg_buffer->sockmanager_socket_out.socket_worker; (*serrno) = _dice_msg_buffer->sockmanager_socket_out.serrno; _dice_return = _dice_msg_buffer->sockmanager_socket_out._dice_return; return _dice_return; }
l4_ipc_call_tag call seems very strange.
Regards Marc
Hi Marc,
Marc CHALAND wrote on 02/22/2008 12:05 PM this:
Sorry Adam, I think I have trouble with my ISP. I didn't get your mail.
From Adam Lackorzynski
I think it has nothing to do with CONFIG_EMBEDDED.
Thank you for this info. So you confirm, to build l4linux with L4con, EMBEDDED should be set on version 2.6.24 ?
With 'sometimes', do you mean it's hard to trigger or rather that it doesn't matter which program you use?
It's easy to trigger (during init). But never at the same moment.
Just for completeness, did you upgrade your Linux distribution you're running inside L4Linux? Or any other change?
I don't remember exactly why, but I had to upgrade generic_dm or dm_phys so that I had to upgrade all TUDOS pkg directory and l4linux. I have another strange behavior with dice : one of my IDL doesn't work with last version of DICE. I had to go back to 238 revision of dice to work. Code generated is very strange :
-----------> IDL : int socket([in] int domain, [in] int type, [in] int protocol, [out] l4_threadid_t *socket_worker, [out] int *serrno);
-------------> last revision of dice on client side : int lwip_sockmanager_socket_call (const_CORBA_Object _dice_corba_obj, int domain /* in */, int type /* in */, int protocol /* in */, l4_threadid_t *socket_worker /* out */, int *serrno /* out */, CORBA_Environment *_dice_corba_env) { /* size = 20 bytes == 5 dwords */ typedef union { struct { long _dice_opcode; int domain; int type; int protocol; } sockmanager_socket_in; struct { l4_umword_t _exception; l4_threadid_t socket_worker; int serrno; int _dice_return; } sockmanager_socket_out; struct { l4_fpage_t _dice_rcv_fpage; l4_msgdope_t _dice_size_dope; l4_msgdope_t _dice_send_dope; l4_umword_t _word[2]; } _word; } lwip_sockmanager_sockmanager_socket_msg_buffer_t; int _dice_return = 0; lwip_sockmanager_sockmanager_socket_msg_buffer_t *_dice_msg_buffer = (lwip_sockmanager_sockmanager_socket_msg_buffer_t*)_dice_corba_env->utcb->values; l4_umword_t _exception __attribute__ ((unused)); l4_msgtag_t tag_dummy __attribute__ ((unused)) = l4_msgtag(0,0,0,0); l4_msgdope_t _dice_result = { raw: 0 }; _dice_msg_buffer->_word._dice_size_dope = L4_IPC_DOPE( sizeof(*_dice_msg_buffer)/sizeof(long)-3, 0); _dice_msg_buffer->sockmanager_socket_in._dice_opcode = LWIP_SOCKMANAGER_SOCKET_OPCODE; _dice_msg_buffer->sockmanager_socket_in.domain = domain; _dice_msg_buffer->sockmanager_socket_in.type = type; _dice_msg_buffer->sockmanager_socket_in.protocol = protocol; do { l4_ipc_call_tag(*_dice_corba_obj, L4_IPC_SHORT_MSG, LWIP_SOCKMANAGER_SOCKET_OPCODE, domain, l4_msgtag(0, 4, 0, 0), /* utcb */ L4_IPC_SHORT_MSG, &_dice_msg_buffer->sockmanager_socket_out._exception, (l4_umword_t*)socket_worker, _dice_corba_env->timeout, &_dice_result, &tag_dummy); } while ((L4_IPC_ERROR(_dice_result) == L4_IPC_SEABORTED) || (L4_IPC_ERROR(_dice_result) == L4_IPC_SECANCELED)); if (DICE_EXPECT_FALSE(L4_IPC_ERROR(_dice_result))) { CORBA_exception_set(_dice_corba_env, CORBA_SYSTEM_EXCEPTION, CORBA_DICE_EXCEPTION_IPC_ERROR, 0); DICE_IPC_ERROR(_dice_corba_env) = L4_IPC_ERROR(_dice_result); return _dice_return; } if (DICE_EXPECT_FALSE(_dice_msg_buffer->sockmanager_socket_out._exception != 0)) { DICE_EXCEPTION_MAJOR(_dice_corba_env) = ((dice_CORBA_exception_type){ _raw: _dice_msg_buffer->sockmanager_socket_out._exception})._corba.major; DICE_EXCEPTION_MINOR(_dice_corba_env) = ((dice_CORBA_exception_type){ _raw: _dice_msg_buffer->sockmanager_socket_out._exception})._corba.repos_id; return _dice_return; } (*socket_worker) = _dice_msg_buffer->sockmanager_socket_out.socket_worker; (*serrno) = _dice_msg_buffer->sockmanager_socket_out.serrno; _dice_return = _dice_msg_buffer->sockmanager_socket_out._dice_return; return _dice_return; }
l4_ipc_call_tag call seems very strange.
Looks fine to me. The generated stubs use UTCB IPC now, which makes them faster for messages that fit into the UTCB (as the one above). (And UTCB IPC can be used cross CPU.)
The address of the UTCB is taken in the stub from the environment variable. This environment variable (_dice_corba_env->utcb) is set per default with l4sys_utcb_get which in turn does 'asm( "%gs:0" )'. The problem with Linux applications (running on L4Linux) is that they are linked to a glibc that uses %gs for its own purposes. Therefore, the UTCB pointer is probably bogus and thus UTCB IPC fails.
If your program runs *inside* L4Linux it should work, because L4Linux (should) provides an own version of l4sys_utcb_get that obtains the correct UTCB address. If your program runs as application *on top* of L4Linux and uses the generated stubs, then you have a problems.
The quick fix is to go back to a version of Dice that does not use UTCB IPC. A better solution is to add a method to the task startup code that obtains the L4 UTCB address before the glibc resets %gs. An own version of l4sys_utcb_get could then fetch the cached UTCB address. (I don't know if this would work, though, as I am not familiar with the startup process of L4Linux tasks.)
Regards, Ron.
From Ronald Aigner:
The address of the UTCB is taken in the stub from the environment variable. This environment variable (_dice_corba_env->utcb) is set per default with l4sys_utcb_get which in turn does 'asm( "%gs:0" )'. The problem with Linux applications (running on L4Linux) is that they are linked to a glibc that uses %gs for its own purposes. Therefore, the UTCB pointer is probably bogus and thus UTCB IPC fails.
Wunderbar :). That explains why I encounter problems with L4Linux.
But this task is abolutely not an L4Linux one. It just uses L4env. The values for domain, type and protocol are 2 1 6 on client side and 0x221401 0x0 0x7069776c on server side. Return value is absolutely anything.
The quick fix is to go back to a version of Dice that does not use UTCB IPC.
Could you tell me which version is the last without UTCB feature ? SVN is not very explicit about it :).
Regards Marc
Marc CHALAND wrote on 02/22/2008 02:21 PM this:
From Ronald Aigner:
The address of the UTCB is taken in the stub from the environment variable. This environment variable (_dice_corba_env->utcb) is set per default with l4sys_utcb_get which in turn does 'asm( "%gs:0" )'. The problem with Linux applications (running on L4Linux) is that they are linked to a glibc that uses %gs for its own purposes. Therefore, the UTCB pointer is probably bogus and thus UTCB IPC fails.
Wunderbar :). That explains why I encounter problems with L4Linux.
But this task is abolutely not an L4Linux one. It just uses L4env. The values for domain, type and protocol are 2 1 6 on client side and 0x221401 0x0 0x7069776c on server side. Return value is absolutely anything.
Now that really sounds strange. You say that the task is running as L4Env task? No L4Linux involved? Not even on the sender/receiver side of the IPC?
The quick fix is to go back to a version of Dice that does not use UTCB IPC.
Could you tell me which version is the last without UTCB feature ? SVN is not very explicit about it :).
I'd go with revision 233 from public repository.
Regards, Ron.
From Ronald Aigner:
Now that really sounds strange. You say that the task is running as L4Env task? No L4Linux involved? Not even on the sender/receiver side of the IPC?
In that case, L4Linux is not even started. Client and server side are pure L4env tasks. More strange : other IPC even from the same tasks work. It seems that there is a bug only for that entry.
I'd go with revision 233 from public repository.
r238 seems to work well for current point. But I didn't do any test on hybrid L4Linux tasks yet.
Regards Marc
Marc CHALAND wrote on 02/22/2008 02:51 PM this:
From Ronald Aigner:
Now that really sounds strange. You say that the task is running as L4Env task? No L4Linux involved? Not even on the sender/receiver side of the IPC?
In that case, L4Linux is not even started. Client and server side are pure L4env tasks. More strange : other IPC even from the same tasks work. It seems that there is a bug only for that entry.
Sorry for the long delay. I build a test for the IDL you sent, but could not find any error. If the task using the IPC is really a pure L4Env task, then this IDL should work. Do you still see the error if you leave L4Linux out of the boot menu?
Greetings, Ron.
From Ronald Aigner: I build a test for the IDL you sent, but could not find any error. If the task using the IPC is really a pure L4Env task, then this IDL should work. Do you still see the error if you leave L4Linux out of the boot menu?
I still have a problem on that API with current version of dice. I will give you more detail next week, as soon as get time :/. Thank you for patch. It works :).
Regards Marc
Hi,
On Fri Feb 22, 2008 at 14:21:37 +0100, Marc CHALAND wrote:
From Ronald Aigner:
The address of the UTCB is taken in the stub from the environment variable. This environment variable (_dice_corba_env->utcb) is set per default with l4sys_utcb_get which in turn does 'asm( "%gs:0" )'. The problem with Linux applications (running on L4Linux) is that they are linked to a glibc that uses %gs for its own purposes. Therefore, the UTCB pointer is probably bogus and thus UTCB IPC fails.
Wunderbar :). That explains why I encounter problems with L4Linux.
This particular issue is fixed now, btw.
Adam
On Fri Feb 22, 2008 at 12:05:44 +0100, Marc CHALAND wrote:
Sorry Adam, I think I have trouble with my ISP. I didn't get your mail.
Not good.
From Adam Lackorzynski
I think it has nothing to do with CONFIG_EMBEDDED.
Thank you for this info. So you confirm, to build l4linux with L4con, EMBEDDED should be set on version 2.6.24 ?
To disable VGA EMBEDDED must be enabled, so yes.
With 'sometimes', do you mean it's hard to trigger or rather that it doesn't matter which program you use?
It's easy to trigger (during init). But never at the same moment.
Ok, still strange, because it works perfectly for me.
Adam
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Marc CHALAND -
Ronald Aigner