Re: [Xenomai-help] BUG fs/buffer.c with Linux 2.6.26,27

[Jan Kiszka <jan.kiszka@domain.hid>]

Philippe Gerum wrote:
> Roman Pisl wrote:
>> Hello Philippe, Jan and other experts,
>> I did some tests on the desktop and the bug is still present.
>>
>> I tried both disabling CONFIG_PREEMPT and applying __ipipe_syscall_root
>> patch.
>>
>> Unfortunately I couldn't test Xenomai from trunk with our application,
>> because events are probably broken - attached example segfaults on
>> rt_event_wait. So I still use 2.4.6.1 and that is the reason for the
>> problem with void rthal_propagate_irq when
>> adeos-ipipe-2.6.27.13-x86-2.2-05.patch is applied.
>>
>> Jan wrote:
>> The tracer log for .27 looks strange - did you apply my
>> ipipe-trace-over-ftrace patch or just enabled the existing code? In the
>> latter case, the .26-based trace log would be nice to cross-check and
>> exclude tracer artifacts.
>>
>> Sorry, but I don't know where this patch comes from. I enabled existing
>> code only.
>>
>> .configs and logs are attached.
>>
> 
> FYI, testev.c is broken; the rt_event_wait() arglist is really wrong: mask_r
> is a mandatory arg that may not be passed as NULL, and the mode/timeout args
> have been inverted.

Ah, good to know. I suspected something like that as I also see such
faults in the return path of __rt_event_wait with 2.4.x and the test
binary I received privately. So this is actually a trigger for the ipipe
issue we have.

I'm almost done with understanding the race in ipipe. It looks like
stalling the root domain in __ipipe_handle_exception when
__rt_event_wait triggers some fault over the Xenomai domain is buggy.
Because this stalled state is then propagated to a different Linux task
context, causing the root domain's IRQ corruption. More on this shortly.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux