Hi, I've tried a more defensive kernel setup & your patch (no.6). The lockup is still there. It happens after a realtime task is started, though I was unable to track exactly when - it does not crash in a debugger, does not crash with strace, breaks SysRq, and printing log messages seems to be delayed (despite flushing). I tried changing the application code (like using more default flags when creating a task, etc). But I did not find a workaround.
I've put the kernel on the web again, including the config (the one that contains "xenomaidp6"). Maybe it might help to track down the bug... Maybe not. Do you have any ideas how to work it around ? Thanks Tomas Tomas Kalibera wrote: > Gilles Chanteperdrix wrote: > >> > 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 >> >> Here comes a 6th patch for this bug, (patch 6 includes patch 5). >> >> >> > I've tested the 6th patch, the lockup is still there. > As far as I can observe, it behaves exactly like with the 5th patch. > > Tomas > > > > > _______________________________________________ > Xenomai-core mailing list > Xenomaifirstname.lastname@example.org > https://mail.gna.org/listinfo/xenomai-core > _______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core