Re: [Xenomai-help] Crash using userspace interrupts

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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

Jan Kiszka wrote:
> Stephan Zimmermann wrote:
> 
>>Am Dienstag, 5. Dezember 2006 16:06 schrieb Jan Kiszka:
>>
>>>Stephan Zimmermann wrote:
>>>
>>>>Hello List,
>>>>I am facing a crashing kernel when I use some rt_interupt_xxx funtions in
>>>>my application.
>>>>
>>>>System: Dualcore AMD with Debian 3.1, kernel 2.7.17.14 with Xenomai SVN
>>>>rev 1920.
>>>>
>>>>Kernel crashes, leaving the following last words in syslog, the system
>>>>keeps responding, but I am unable to restart my application.
>>>>
>>>><syslog>
>>>>I-pipe: Domain Xenomai registered.
>>>>Dec  5 15:24:07 localhost kernel: Xenomai: hal/x86 started.
>>>>Dec  5 15:24:07 localhost kernel: Xenomai: real-time nucleus v2.3-rc1
>>>>(Baroque) loaded.
>>>
>>>#1920 implies -rc2. Something is probably inconsistent in your build.
>>
>>Well you where right, my build was broken somehow. I reinstalled 
>>everything (Kernel, Xenomai) from clean sources, leading to a build 
>>which claims to be rc2. Nevertheless my system crashes, giving 
>>the same errormessages in syslog. 
>>Things change if I run the same program on a single-cpu machine 
>>or compile my kernel without SMP support, then everything seems to work fine.
>>
>>Thanks again, Stephan
>>
>><syslog>
>>I-pipe: Domain Xenomai registered.
>>Dec  6 11:38:08 localhost kernel: Xenomai: hal/x86 started.
>>Dec  6 11:38:08 localhost kernel: Xenomai: real-time nucleus v2.3-rc2 (Baroque) loaded.
>>Dec  6 11:38:08 localhost kernel: Xenomai: starting native API services.
>>Dec  6 11:39:13 localhost kernel:        waiter = kernel/xenomai/nucleus/intr.c:627 (xnintr_attach(), CPU #1)
>>Dec  6 11:39:13 localhost kernel:        owner  = <NULL>:0 (<NULL>(), CPU #0)
>>Dec  6 11:39:13 localhost kernel:        d8e31e88 c02d426e c02dfcdd f96a3385 00000000 00000000 00000000 00000000
>>Dec  6 11:39:13 localhost kernel:        00000000 c03bf080 db303124 00000000 f966af7b db30312c db303120 00000000
>>Dec  6 11:39:13 localhost kernel:        00000001 00000000 00000001 00000000 00000000 00000000 db303120 00000007
>>Dec  6 11:39:13 localhost kernel: Call Trace:
>>Dec  6 11:39:13 localhost kernel:  <f96a3385> xnintr_attach+0xd1/0x287 [xeno_nucleus]  <f966af7b> rt_intr_create+0x941/0x988 [xeno_native]
>>Dec  6 11:39:13 localhost kernel:  <f965efba> __rt_intr_create+0xaf/0xf6 [xeno_native]  <f965eec5> rt_intr_handler+0x0/0x46 [xeno_native]
>>Dec  6 11:39:13 localhost kernel:  <f9664227> rt_mutex_release+0x323/0x32f [xeno_native]  <f96c87b3> hisyscall_event+0x13e/0x251 [xeno_nucleus]
>>Dec  6 11:39:13 localhost kernel:  <f96c8675> hisyscall_event+0x0/0x251 [xeno_nucleus]  <c0135c55> __ipipe_dispatch_event+0xd6/0x1dc
>>Dec  6 11:39:13 localhost kernel:  <c011075a> __ipipe_syscall_root+0x9e/0x147  <c0102ad6> sysenter_past_esp+0x3b/0x67
>>Dec  6 11:39:13 localhost kernel: Xenomai: watchdog triggered -- killing runaway thread 'CAN-ISR-2'
>></syslog>
> 
> 
> That all sounds quite weird, also the spinlock debugger output above
> that says no one is owning the lock, but we are spinning on it.

This may happen if the lock is not initialized, because an unlocked lock
need to be initialized with ~0. Does the following patch help ?

-- 
                                                 Gilles Chanteperdrix

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xeno-init-intrlock.diff --]
[-- Type: text/x-patch; name="xeno-init-intrlock.diff", Size: 375 bytes --]

Index: ksrc/nucleus/intr.c
===================================================================
--- ksrc/nucleus/intr.c	(révision 1920)
+++ ksrc/nucleus/intr.c	(copie de travail)
@@ -40,7 +40,7 @@
 #define XNINTR_MAX_UNHANDLED	1000
 
 #ifdef CONFIG_SMP
-xnlock_t intrlock;
+xnlock_t intrlock = XNARCH_LOCK_UNLOCKED;
 #endif /* CONFIG_SMP */
 
 xnintr_t nkclock;