On Mon, 2007-03-05 at 13:44 +0100, Stephan Zimmermann wrote:
> Jan Kiszka schrieb:
> > That happens when you overload your box with the test so that Linux does
> > not totally starve, just a bit too much so that it thinks it ran into a
> > soft-lockup. I've seen this here as well.
> OK, you are right. My mistake.
> But back to business, the Celeron M keeps crashing, even at 1 kHz. We
> have figured out that it hast s.th. to do with rt_queue_create call. The
> modified code we use for testing is attached to this mail.
> 'queue_main.cpp' lets the system crash, while 'noqueue_main.cpp' does
> not. The .config of the linux kernel is also attached.
> Hopefully this helps to find a solution.
Unfortunately, I still cannot trigger this issue here. Here is what I'm
doing to try reproducing it:
- x86 kernel 2.6.20-1.7-03 stock, Xenomai v2.3.1 stock
- your Xenomai configuration, and specifically the nucleus and the
native interface built as modules, all Xenomai debug switches on,
- booting and starting X
- running the following script in a loop for 100 times :
rmmod xeno_native xeno_nucleus
- reboot (No obvious sign of system corruption, shutdown goes smoothly,
hw reboot is properly triggered after a graceful stop)
Does this match the way you are trigerring the iussue yourself?
Xenomai-core mailing list