Philippe Gerum wrote:
> On Mon, 2007-02-12 at 14:49 +0100, Jan Kiszka wrote:
> 
>>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.
> 
> 
> Now that vmalloc & ioremap memory may have their pte set on demand anew
> due to the nocow patch, minor faults in kernel space are possible again,
> but this should only happen on behalf of the Linux domain, this is not
> expected to happen in primary mode.

Does not a primary mode IRQ handler borrow the mmu context from the
tasks it preempts ?

-- 
                                                 Gilles Chanteperdrix

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to