Re: [Xenomai-help] Kernel crash during queue create/destroy

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2465 bytes --]

Stephan Zimmermann wrote:
> Am Mittwoch, 15. November 2006 14:19 schrieb Dmitry Adamushko:
>> Hello,
>>
>> I got some trouble with the native skin and queues, when creating /
>> deleting
>>
>>> queues, my Kernel sometimes (actually very often...) crashes, leading to
>>> a frozen system, with my Xenomai program continuing until it returns. I
>>> tried
>>> to isolate / reproduce the problem, which lead me to the following
>>> demo-code.
>> it looks like there is some "misunderstanding" between
>>
>> (1) rt_queue_delete() -> xnregistry_remove()
>>
>> and
>>
>> (2) registry_proc_callback() which crushes in remove_proc_entry().
>>
>> You may follow the logic in ksrc/nucleus/registry.c.
>>
>> rt_queue_create() -> xnregistry_enter() -> ... -> registry_proc_callback()
>>
>> rt_queue_delete() -> xnregistry_remove() -> ... registry_proc_unexport()
>>
>> I don't have enough time to investigate further right now, but
>> nevertheless, could you apply the following patch and let us know of the
>> outcome?
> 
> Thanks for your fast response. I just applied (and recompiled everything...) 
> the patch you attached to your last Post. It doesn't seem to change  anything 
> for me. I attached the entries from syslog the test produced.
> 

/me unfortunately failed to reproduce your problem here. Instead, I
found a regression in SVN head - different story for a different thread.

I have another debugging suggestion:

Enable CONFIG_IPIPE_TRACE_MCOUNT (under Kernel Hacking) and patch the
kernel as follows:

--- arch/i386/mm/fault.c.orig
+++ arch/i386/mm/fault.c
@@ -515,6 +515,8 @@ no_context:

 	bust_spinlocks(1);

+	ipipe_trace_freeze(0);
+
 	if (oops_may_print()) {
 	#ifdef CONFIG_X86_PAE
 		if (error_code & 16) {

Then recompile it and let your test run. After (and if...) it crashed,
you should look at /proc/ipipe/trace/frozen. This will contain a
back-trace around the crash. Tune the output via, e.g.,

	echo 1000 > /proc/ipipe/trace/back_trace_points
	(see also our wiki on more information about the tracer)

so that at least the path from the previous rt_queue_create up to the
crash is visible. This will give a call history (not just a stack
back-trace), as the tracer records all function calls in the kernel. May
help us to understand if we hit an unexpected function schedule here. It
all sounds like some rare race to me. I hope the trace will not make it
vanish...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]