Linux 2.6.24 L4FB and VGA_CONSOLE

[Ronald Aigner]

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.

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