Philippe Gerum wrote:
> On Mon, 2007-02-12 at 14:16 +0100, Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Jan Kiszka wrote:
>>>
>>>> 2.6.19 didn't magically start to work as well. Instead I have a back
>>>> trace now, see attachment.
>>>>
>>>> I included a full set of 16k points, but the thrilling things are around
>>>> -73 to -25: Some Linux process with IRQs on gets preempted by an RT-IRQ
>>>> (RTnet NIC). That triggers an RT kernel thread to run for a while (RTnet
>>>> stack manager, prio 98). But when returning to Linux again, its IRQs
>>>> remain masked now. The reason must be that weird exception at -62. Don't
>>>> know where it comes from and why is there no report about THAT issue in
>>>> the kernel logs.
>>>
>>> The cause of this page fault will get tracked down later today, but the
>>> way it is handled already causes some doubts to me. To make discussion
>>> easier, here is the relevant excerpt from the trace:
>> Maybe this fault is due to the No-cow patch ? Before the no-cow patch,
>> vmalloced areas were added to all processes page directories, now they
>> are added only to the page directories of processes with the VM_PINNED
>> flag. So, if ipipe_test_root tries to access some module memory area
>> over the context of a non-realtime thread, a fault will occur.
>>
> 
> Yes, it's a minor fault occurring due to on-demand memory mapping, this
> is why we don't get any alarming message in the kernel log.
> 

Looks like it's something that should never happen, for sure. But are we
fine with screwing up the Linux IRQ state nevertheless? In other words,
are we seeing one or two ipipe issues here?