Philippe Gerum wrote:
> On Fri, 2010-01-22 at 17:58 +0100, Jan Kiszka wrote:
>> Hi guys,
>> we are currently trying to catch an ugly Linux pipeline state corruption
>> on x86-64.
>> Conceptual question: If a Xenomai task causes a fault, we enter
>> ipipe_trap_notify over the primary domain and leave it over the root
>> domain, right? Now, if the root domain happened to be stalled when the
>> exception happened, where should it normally be unstalled again,
>> *for_that_task*? Our problem is that we generate a code path where this
>> does not happen.
> xnhadow_relax -> ipipe_reenter_root -> finish_task_switch ->
> finish_lock_switch -> unstall
> Since xnshadow_relax is called on behalf the event dispatcher, we should
> expect it to return with the root domain unstalled after a domain
> downgrade, from primary to root.
That all happens as expected. But then __ipipe_handle_exception - as it
last duty - ruins our day by replaying an unrelated root state.
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Xenomai-core mailing list