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, 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
#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.



Xenomai-core mailing list

Reply via email to