Ronald Aigner ra3 at os.inf.tu-dresden.de
Mon Jul 24 13:05:47 CEST 2006

Hash: SHA1

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.

HTH, Ron.
- --
Mit freundlichen Gruessen / with regards
ra3 @ inf.tu-dresden.de
Version: GnuPG v1.4.3 (GNU/Linux)


More information about the l4-hackers mailing list