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 Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core