Tomas Kalibera wrote:

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.

Jumping late on this, I didn't find any (user space) test case for the observed bug in this thread. Can you provide something? The simpler, the better. It may even contain bugs itself, it just has to trigger the kernel oops reliably.

Then I saw in your .config that your kernel is optimized for AMD K6. In order to prepare "exporting" the bug, could you check that more generic CONFIG_M586TSC makes no difference? Also, if you happen to have a second, different box (/wrt CPU type & speed) at hand, it would be nice to know that the issue is present there as well. But the latter is also something we can try once a test case is available. My preferred target will be QEMU, because that one can quite nicely be debugged even if the box is hopelessly locked up.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to