IPC problem with dice-3.3.0

[Carsten Weinhold]

Am 20.03.2009 um 00:58 schrieb Marcel Selhorst:

> Hi Carsten,

Hi!

> [...]
> Now the IPCs are working, but I identified another problem, that I  
> am not able
> to solve:
>
> I have the following interface:
>
> int register([in, size_is(name_len), max_is(MAX_NAME_LEN)] char   
> *name,
>             [in]                                          long    
> name_len,
>             [in]                                          long   in1,
>             [out]                                         long  *out1,
>             [out]                                         long   out2
>            );
>
> long read   ([in]                                          long   in1,
>             [in]                                          long   in2,
>             [in]                                          long    
> bytes_to_read,
>             [out, max_is(MAX_PAGE_SIZE)]                  char    
> read_buffer[]
>            );
> [...]
> 3) L4Linux kernel module
>
> fails... The kernel module registers itself during the __init phase  
> via the
> "register" function and this function also works.
> But as soon as I try to execute a "read"-call, I get:
>
>    --Unset id on stack (c)----------------------------------IP:  
> 00401e30
> [l4lx.cpu0] (10.05) jdb: g
> 00000505.00000002
> failed CLI: 00000010.00000005
>
>    --Unset id on stack (c)----------------------------------IP:  
> 00401e30
> [l4lx.cpu0] (10.05) jdb: g
> 0000050500000002
> failed STI: 00000010.00000005
>
> The strange thing is, that the DICE-environmnent is set (otherwise the
> names_query_name() and the register()-method would fail). I even  
> tried to put
> the env manually on the stack prior calling via:
> {
>  DICE_DECLARE_ENV(env);
>  result = read(...);
> }
> But that didn't help either.
>
> Do you have any idea, what I might be missing?

Hard to tell without knowing any details about what you are doing in  
the L4Linux kernel. You cannot "just use" IDL server stubs in the  
L4Linux kernel, they have to run in interrupt threads (the ORe driver  
in drivers/net/l4ore.c might serve as an example). The error message  
you get might also indicate a stack overrun (maybe the generated DICE  
code uses too much stack ... ?).

> [...]

Carsten