Philippe Gerum wrote:
> On Mon, 2007-02-12 at 15:39 +0100, Gilles Chanteperdrix wrote:
> 
>>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 ?
>>
> 
> 
> Yes, this is where the problem stands if we happen to preempt a regular
> task and tread over code which might trigger minor faults. The best way
> to check this would be to somehow enable VM_PINNED for all tasks. Back
> to square #1.
> 

Ok. I'll try to change this and send a patch ASAP.

-- 
                                                 Gilles Chanteperdrix

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

Reply via email to