All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Scholz <steven.scholz@domain.hid>
To: Xenomai-core@domain.hid
Subject: Re: [Xenomai-core] latency hangs on AT91RM9200
Date: Fri, 23 Feb 2007 14:50:26 +0100	[thread overview]
Message-ID: <45DEF122.2060406@domain.hid> (raw)
In-Reply-To: <45DEE913.9080809@domain.hid>

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

Gilles,

>> I am running 2.6.19 + adeos-ipipe-2.6.19-arm-1.6-02.patch + xenomai-svn-2007-02-22
>> on an AT91RM9200 (160MHz/80MHz).
>>
>> When starting "latency -p 200" it runs for a while printing
>>
>> RTT|  00:05:37  (periodic user-mode task, 200 us period, priority 99)
>> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
>> RTD|      11.200|     139.200|     236.800|       1|      10.800|     280.800
>>
>> but then hangs. The timer LED stops blinking. No "soft lockup detected" appears.
> 
> The only explanation I have is that the period is too small. I do not
> observe the same behaviour with latency -p 1000. Note that setting the
> period to a value comparable to the latency is not considered a normal
> use of Xenomai. 

Sure but I would still not expect the system to hang!
As I said missing a deadline is bad but ok.
But hanging the whole system is not quite ok.

>> Using a BDI200 it looks like that in kernel/sched.c:schedule() he is returning
>> in the lines
>>
>> #ifdef CONFIG_IPIPE
>>         if (unlikely(!ipipe_root_domain_p))
>>                 return;
>> #endif /* CONFIG_IPIPE */
>>
>> When stepping trough I only see him getting into schedule() but leaving
>> it in the above lines and in include/linux/proc_fs.h:proc_net_fops_create() ...
> 
> Ok. Thanks for pointing this out. That is interesting, but not very
> informative. It would be interesting if you could get the full
> backtrace. What would be also interesting would be to set a break point
> on the timer interrupt handler and to follow what happens from timer
> interrupt to timer interrupt.

I tried! Attached the patch I used. Since teh scheduler hangs I can't use normal printk(), right?

*ipipe_current_domain != ipipe_root_domain !
*ipipe_current_domain = c01fc2c0
*ipipe_root_domain    = c01af2c0

But I don't get the output of __backtrace()!

my_printk() works with __backtrace(). The dump of a soft lockup works.


Steven


[-- Attachment #2: debug-xenomai.patch --]
[-- Type: text/x-patch, Size: 2602 bytes --]

Index: linux-2.6.19/arch/arm/lib/backtrace.S
===================================================================
--- linux-2.6.19.orig/arch/arm/lib/backtrace.S
+++ linux-2.6.19/arch/arm/lib/backtrace.S
@@ -100,7 +100,7 @@ ENTRY(c_backtrace)
  */
 1007:		ldr	r0, =.Lbad
 		mov	r1, frame
-		bl	printk
+		bl	my_printk
 		ldmfd	sp!, {r4 - r8, pc}
 		.ltorg
 		
@@ -134,12 +134,12 @@ ENTRY(c_backtrace)
 		ldr	r2, [stack], #-4
 		mov	r1, reg
 		adr	r0, .Lfp
-		bl	printk
+		bl	my_printk
 2:		subs	reg, reg, #1
 		bpl	1b
 		teq	r7, #0
 		adrne	r0, .Lcr
-		blne	printk
+		blne	my_printk
 		mov	r0, stack
 		ldmfd	sp!, {instr, reg, stack, r7, r8, pc}
 
Index: linux-2.6.19/include/linux/kernel.h
===================================================================
--- linux-2.6.19.orig/include/linux/kernel.h
+++ linux-2.6.19/include/linux/kernel.h
@@ -146,6 +146,12 @@ asmlinkage int vprintk(const char *fmt, 
 	__attribute__ ((format (printf, 1, 0)));
 asmlinkage int printk(const char * fmt, ...)
 	__attribute__ ((format (printf, 1, 2)));
+
+
+asmlinkage int my_printk(const char * fmt, ...)
+        __attribute__ ((format (printf, 1, 2)));
+
+
 #else
 static inline int vprintk(const char *s, va_list args)
 	__attribute__ ((format (printf, 1, 0)));
Index: linux-2.6.19/kernel/printk.c
===================================================================
--- linux-2.6.19.orig/kernel/printk.c
+++ linux-2.6.19/kernel/printk.c
@@ -524,6 +524,21 @@ void __ipipe_flush_printk (unsigned virq
 	spin_unlock_irqrestore(&__ipipe_printk_lock, flags);
 }
 
+/*FIXME*/
+extern void printascii(const char *);
+asmlinkage int my_printk(const char *fmt, ...)
+{
+        va_list va;
+        char buff[256];
+
+        va_start(va, fmt);
+        vsprintf(buff, fmt, va);
+        va_end(va);
+
+        printascii(buff);
+	return 0;
+}
+
 asmlinkage int printk(const char *fmt, ...)
 {
 	int r, fbytes, oldcount;
Index: linux-2.6.19/kernel/sched.c
===================================================================
--- linux-2.6.19.orig/kernel/sched.c
+++ linux-2.6.19/kernel/sched.c
@@ -3327,8 +3327,14 @@ asmlinkage void __sched schedule(void)
 	struct rq *rq;
 
 #ifdef CONFIG_IPIPE
-	if (unlikely(!ipipe_root_domain_p))
+	if (unlikely(!ipipe_root_domain_p)) {
+		my_printk("ipipe_current_domain != ipipe_root_domain !\n");
+		my_printk("ipipe_current_domain = %p\n", ipipe_current_domain);
+		my_printk("ipipe_root_domain    = %p\n", ipipe_root_domain);
+		__backtrace();
+		while (1) { barrier();};
 		return;
+	}
 #endif /* CONFIG_IPIPE */
 	/*
 	 * Test if we are atomic.  Since do_exit() needs to call into


  parent reply	other threads:[~2007-02-23 13:50 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-23 11:27 [Xenomai-core] latency hangs on AT91RM9200 Steven Scholz
2007-02-23 13:16 ` Gilles Chanteperdrix
2007-02-23 13:26   ` Philippe Gerum
2007-02-23 13:53     ` Steven Scholz
2007-02-23 13:50   ` Steven Scholz [this message]
2007-02-23 13:57     ` Philippe Gerum
2007-02-23 13:56       ` Steven Scholz
2007-02-23 14:12         ` Philippe Gerum
2007-02-23 14:16           ` Steven Scholz
2007-02-23 14:11     ` Gilles Chanteperdrix
2007-02-23 14:14       ` Steven Scholz
2007-02-23 14:21         ` Jan Kiszka
2007-02-23 15:02           ` Steven Scholz
2007-02-23 15:09             ` Jan Kiszka
2007-02-23 14:24         ` Gilles Chanteperdrix
2007-02-23 14:33         ` Steven Scholz
2007-02-23 15:05           ` Gilles Chanteperdrix
2007-02-23 14:36         ` Jan Kiszka
2007-02-23 14:39           ` Steven Scholz
2007-02-23 14:41             ` Jan Kiszka
2007-02-26 10:11               ` Steven Scholz
2007-02-23 13:25 ` Philippe Gerum
2007-02-23 13:49 ` Steven Scholz
2007-02-23 15:14 ` Steven Scholz
2007-02-23 15:23   ` Gilles Chanteperdrix
2007-02-23 15:28     ` Jan Kiszka
2007-02-23 16:41   ` Gilles Chanteperdrix
2007-02-26 10:17     ` Gilles Chanteperdrix
2007-02-26 11:21       ` Gilles Chanteperdrix
2007-02-26 13:36         ` Steven Scholz
2007-03-08  8:28         ` Steven Scholz
2007-03-08  8:43           ` Gilles Chanteperdrix
2007-03-08  8:46             ` Steven Scholz
2007-03-08  9:18               ` Gilles Chanteperdrix

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45DEF122.2060406@domain.hid \
    --to=steven.scholz@domain.hid \
    --cc=Xenomai-core@domain.hid \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.