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 ?


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

Xenomai-core mailing list

Reply via email to