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. > But are we > fine with screwing up the Linux IRQ state nevertheless? In other words, > are we seeing one or two ipipe issues here? The I-pipe would only restore the virtual flag as seen on entry from an exception on behalf of the Linux domain, not in primary mode. -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
