Tomas Kalibera wrote:
> Gilles Chanteperdrix wrote:
> > Tomas Kalibera wrote:
> > >
> > > Hi Gilles,
> > >
> > > I've recompiled the kernel again from scratch and got the same lock up.
> > > Fix 5 does not help... If you want to inspect the exact kernel I used,
> > > it's again at http://www.cs.purdue.edu/~tkaliber/crash, the one with
> > > "p5" in its name.
> > >
> > > Tomas
> >
> > But... do you get the lock-up without the patch ?
> >
> >
> No. Or, more precisely, not the same one. With this patch (5), the
> system locks up as soon as the application starts. It does not print
> any stack trace.
> Without the patch, the system gets to unusable state when the
> application calls clone/fork, and it does produce a stack trace (those I
> was sending you before). It seems to be more alive (processes start, but
> crash, because of garbled preempt_count).
>
> The crashes are perfectly repeatable on the system I have. So, the
> crashes make no sense to you, right ? I can indeed try to go the
> defensive path and try an older kernel or something, but if there is a
> Xenomai bug, it would be nice to find it... The same for kernel bug,
> indeed.
Of course, we are looking for all bugs. But please tell me: do you get
the lock-up even before fork is called ? If not, could you verify that
at least some Xenomai programs run correctly, for instance latency ?
Looking at the code, I think I found a bug, but I doubt it could cause a
lockup. The definition of VM_PINNED in include/linux/mm.h collides with
another bit used by Linux, so this defintion should be changed from:
#define VM_PINNED 0x08000000
to:
#define VM_PINNED 0x10000000
I will now try, if possible, to reproduce the bug on a x86 box of mine
and will keep you informed.
--
Gilles.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
