DICE_NO_REPLY error

[Ronald Aigner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry, forgot the reference:

Ronald Aigner wrote on 24.07.2006 13:05 this:
> 
> Michael Scheibel wrote on 24.07.2006 12:52 this:
>>>> Michael Scheibel wrote on 21.07.2006 17:20 this:
>>>>> Running the generated stubs we noticed that ~0.89% of the IPC
>>>>> transactions fail. In such a case the parameters passed to the server
>>>>> still contain their initialization values on return. The client trace
>>>>> says "ipc error c0" and the server trace says "DICE_NO_REPLY".
>>>> IPC error code 0xc0 is "IPC: Receive operation aborted". This usually
>>>> only occurs if the thread's state is changed (using the l4_exregs system
>>>> call). My first guess is that either server or client are L4Linux
>>>> applications and L4Linux is changing the thread state. That would
>>>> axplain the "ipc error c0". Because the IPC is aborted, the parameters
>>>> are not overwritten and thus still contain their initial values.
>>> You're perfectly right, both client and server are L4Linux applications. 
>>> However, I still don't understand what the l4_exregs syscall does and how it 
>>> affects the state of the server and/or client thread. Second, I wonder if 
>>> there is an option to avoid the resulting IPC aborts. The only solution I can 
>>> think of are manual retransmissions in case of a failure (which is not really 
>>> a solution but rather a work-around).
> For a full description of the functionality of the l4_exregs syscall,
> please refer to the L4 version 2 manual [1].
> 
> The interesting effects for this scenario are: Either client or server
> thread are interrupted in their execution, because their execution
> environment -- L4Linux -- decided to suspend these threads (or one of
> them). This is fully valid, because L4Linux is the scheduler of these
> threads. After L4Linux resumes the threads they get an error code
> delivered informing them about the aborted IPC operation.
> 
> Thus you really want that IPC error code to get reflected, because
> that's the only chance to determine if the IPC really got through and
> the results are valid or if the IPC was aborted and you rather should
> not use the results. An application can then handle the error code any
> way it seems fit. It could ignore the error and simply continue
> execution; it could simply retransmit the request; it could run a more
> complicated recovery protocol. So you don't want to loose that error
> code somewhere in the kernel or generated stub.
> 
> Thus retransmission is not the only solution in case of failure and
> surely not a work-around.

[1] http://l4hq.org/docs/manuals/Ln-86-21.pdf
_______________________________________________
l4-hackers mailing list
l4-hackers at os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

- --
Mit freundlichen Gruessen / with regards
ra3 @ inf.tu-dresden.de
http://os.inf.tu-dresden.de/~ra3/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFExKqgvCdOf9l7ipgRApFxAJ4vGvCM5D6+Ydgyv4Tc6VdwFLtSxACfTLcF
Mw1HCkzFpA0HvamajMSuyhs=
=zSJw
-----END PGP SIGNATURE-----