[Xenomai-core] Re: [PATCH] fix tracer compilation issues
Jan Kiszka wrote: Hi Philippe, two minor updates I fixed since your last merge. The first one triggers if the tracer tries to warn of debugging switch related latencies. The second one when building very specific out-of-tree modules against the kernel (here: madwifi with its binary-only component), stumbling over -pg vs. -fomit-frame-pointer. No need for a separate ipipe release from my POV, just apply for the next round. Ok, queued. Thanks. Jan --- ./kernel/ipipe/tracer.c.orig2006-01-07 13:28:01.0 +0100 +++ ./kernel/ipipe/tracer.c 2006-01-08 23:08:45.0 +0100 @@ -821,7 +821,7 @@ static void *__ipipe_frozen_prtrace_star -- --\n, UTS_RELEASE, IPIPE_ARCH_STRING); - __ipipe_print_dbgwarning(); + __ipipe_print_dbgwarning(m); seq_printf(m, Freeze: %lld cycles, Trace Points: %d (+%d)\n\n, print_path-point[print_path-begin].timestamp, print_pre_trace+1, print_post_trace); --- ./kernel/ipipe/Kconfig.orig 2006-01-07 13:28:01.0 +0100 +++ ./kernel/ipipe/Kconfig 2006-01-07 14:24:50.0 +0100 @@ -17,6 +17,7 @@ config IPIPE_STATS config IPIPE_TRACE bool Latency Tracing depends on IPIPE PROC_FS + select FRAME_POINTER default n ---help--- Activate this option if you want to use per-function tracing of -- Philippe.
Re: [Xenomai-core] Two patches for the documentation
Am Sonntag, 8. Januar 2006 11.53 schrieb Philippe Gerum: Niklaus Giger wrote: Hi ... Index: sim/README === --- sim/README (Revision 392) +++ sim/README (Arbeitskopie) @@ -28,7 +28,11 @@ Building the simulator == -You will need the libelf, libpng, tcl8.x/tk8.x and tix41 _development +The simulator does not build with GCC 4.0 or later. + +Currently it does not work on PowerPC systems. + Why? xenoscope is not even able to open a window as apparently it goes somewhere into a recursion. I do not know however how to debug it. gdb /usr/xenomai/bin/xenoscope GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Starting program: /usr/xenomai/bin/xenoscope [Thread debugging using libthread_db enabled] [New Thread 805421056 (LWP 25333)] [New Thread 813860064 (LWP 25336)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 805421056 (LWP 25333)] 0x0f80c2e8 in strchr () from /lib/tls/libc.so.6 (gdb) info stack #0 0x0f80c2e8 in strchr () from /lib/tls/libc.so.6 #1 0x0fef3958 in TkpGetFontFamilies () from /usr/lib/libtk8.4.so.0 #2 0x0fef3958 in TkpGetFontFamilies () from /usr/lib/libtk8.4.so.0 #3 0x0fef3958 in TkpGetFontFamilies () from /usr/lib/libtk8.4.so.0 #4 0x0fef3958 in TkpGetFontFamilies () from /usr/lib/libtk8.4.so.0 .. #63 0x0fef3958 in TkpGetFontFamilies () from /usr/lib/libtk8.4.so.0 Previous frame inner to this frame (corrupt stack?) Best regards -- Niklaus Giger
Re: [Xenomai-core] [PATCH, RFC] nucleus:shared irq, draft v.2
Dmitry Adamushko wrote:
Hi everybody,
I'm presenting it one last time as a draft, so it's a right time to give all
the remarks concerning design/implementation issues for all interested
parties.
Any feedback is wellcome.
--
Best regards,
Dmitry Adamushko
My mail client unfortunately refused to inline your patches, so I have to:
--- intr-cvs.c2005-12-02 19:56:20.0 +0100
+++ intr.c2006-01-09 21:26:44.0 +0100
[...]
@@ -204,11 +242,66 @@
int xnintr_attach (xnintr_t *intr,
void *cookie)
{
+rthal_irq_handler_t irq_handler;
+unsigned irq = intr-irq;
+xnshared_irq_t *shirq;
+int err = 0;
+spl_t s;
+
intr-hits = 0;
intr-cookie = cookie;
-return xnarch_hook_irq(intr-irq,xnintr_irq_handler,intr-iack,intr);
+
+xnlock_get_irqsave(nklock,s);
+
+irq_handler = rthal_irq_handler(rthal_domain,irq);
+
+if (irq_handler)
+ {
+ xnintr_t *old;
+ shirq = rthal_irq_cookie(rthal_domain,irq);
+
+ if (irq_handler != xnintr_irq_handler)
+ {
+ err = -EBUSY;
+ goto unlock_and_exit;
+ }
+
+ old = link2intr(getheadq(shirq-handlers));
+
+ if (!(old-flags intr-flags XN_ISR_SHARED))
+ {
+ err = -EBUSY;
+ goto unlock_and_exit;
+ }
+
+ appendq(shirq-handlers,intr-link);
+ }
+else
+ {
+ shirq = xnmalloc(sizeof(*shirq));
Why not allocating that piece of memory before taking the global lock?
If you don't need it, you can drop it again afterward. If you need but
the returned pointer is NULL, you can still check at the same place you
do now. Just an idea to avoid complex functions inside the global lock
for new xeno-code.
+
+ if (!shirq)
+ {
+ err = -ENOMEM;
+ goto unlock_and_exit;
+ }
+
+ initq(shirq-handlers);
+ appendq(shirq-handlers,intr-link);
+
+ err = xnarch_hook_irq(irq,xnintr_irq_handler,intr-iack,shirq);
+
+ if (err)
+ xnfree(shirq);
+ }
+
+unlock_and_exit:
+
+xnlock_put_irqrestore(nklock,s);
+return err;
}
+
/*!
* \fn int xnintr_detach (xnintr_t *intr)
* \brief Detach an interrupt object.
@@ -241,7 +334,32 @@
int xnintr_detach (xnintr_t *intr)
{
-return xnarch_release_irq(intr-irq);
+unsigned irq = intr-irq;
+xnshared_irq_t *shirq;
+int cleanup = 0;
+int err = 0;
+spl_t s;
+
+xnlock_get_irqsave(nklock,s);
+
+shirq = rthal_irq_cookie(rthal_domain,irq);
+
+removeq(shirq-handlers,intr-link);
+
+if (!countq(shirq-handlers))
+ {
+ err = xnarch_release_irq(irq);
+ cleanup = 1;
+ }
+
+xnlock_put_irqrestore(nklock,s);
+
+xnintr_shirq_spin(shirq);
+
+if (cleanup)
+ xnfree(shirq);
+
+return err;
}
/*!
@@ -350,17 +468,45 @@
I guess here starts the new IRQ handler. BTW, diff -p helps a lot when
reading patches as a human being and not as a patch tool. ;)
{
xnsched_t *sched = xnpod_current_sched();
-xnintr_t *intr = (xnintr_t *)cookie;
-int s;
+xnshared_irq_t *shirq = (xnshared_irq_t *)cookie;
+xnholder_t holder;
+spl_t flags;
+int s = 0;
xnarch_memory_barrier();
xnltt_log_event(xeno_ev_ienter,irq);
+xnlock_get_irqsave(nklock,flags);
+
+shirq = rthal_irq_cookie(rthal_domain,irq);
+xnintr_shirq_lock(shirq);
+
+xnlock_put_irqrestore(nklock,flags);
Why _irqsave in IRQ context?
Regarding this locking isssue in general, I first had some RCU-mechanism
in mind to avoid the reader-side lock in the IRQ handler. But as IRQs
typically touch some nucleus service with its own nklock-acquire anyway,
optimising this here does not seem to be worth the effort now. As long
as we have the global lock, it's ok and much simpler I think.
+
+if (!shirq)
+ {
+ xnintr_shirq_unlock(shirq);
+ xnltt_log_event(xeno_ev_iexit,irq);
+ return;
+ }
+
++sched-inesting;
-s = intr-isr(intr);
+
+holder = getheadq(shirq-handlers);
+
+while (holder)
+ {
+ xnintr_t *intr = link2intr(holder);
+ holder = nextq(shirq-handlers,holder);
+
+ s |= intr-isr(intr);
+ ++intr-hits;
+ }
+
+xnintr_shirq_unlock(shirq);
+
--sched-inesting;
-++intr-hits;
if (s XN_ISR_ENABLE)
xnarch_enable_irq(irq);
Looking forward to see this in Xenomai - at letting some real tests run
with it. :)
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Xenomai-core] latency kernel part crashes on ppc64
Philippe Gerum wrote:
Likely not this time (keep it cold anyway, who knows); I strongly suspect a
bug in
xnarch_switch_to() for all archs but x86
Now that you are talking about it, I may be the one who owes a beer to
everyone by first having put a bug in ia64 context-switch code... If I
am not wrong, the bug should be observed on ia64 too. Unfortunately, I
am unable to compile my ia64 kernel right now, so I wrote a patch for
power PC, and would be glad if some power PC owner could try it.
It should work on PPC 64 too...
--
Gilles Chanteperdrix.
Index: include/asm-powerpc/system.h
===
--- include/asm-powerpc/system.h(revision 410)
+++ include/asm-powerpc/system.h(working copy)
@@ -182,13 +182,19 @@
{
struct task_struct *prev = out_tcb-active_task;
struct task_struct *next = in_tcb-user_task;
+static unsigned long last_ksp;
+static xnarchtcb_t *last_tcb;
+last_tcb = out_tcb;
in_tcb-active_task = next ?: prev;
if (next next != prev) /* Switch to new user-space thread? */
{
struct mm_struct *mm = next-active_mm;
+if (prev != out_tcb-user_task)
+last_ksp = prev-thread.ksp;
+
/* Switch the mm context.*/
#ifdef CONFIG_PPC64
@@ -245,6 +251,22 @@
else
/* Kernel-to-kernel context switch. */
rthal_switch_context(out_tcb-kspp,in_tcb-kspp);
+
+/* If we are not the epilogue of a regular linux schedule(),... */
+if (likely(test_bit(xnarch_current_cpu(),rthal_cpu_realtime))
+/* we are a user-space thread,... */
+out_tcb-user_task
+/* the last context switch used linux switch routine,... */
+last_tcb-active_task != out_tcb-user_task
+/* but the last xenomai context was a kernel thread,... */
+last_tcb-user_task != last_tcb-active_task)
+{
+/* then linux context switch routine saved kernel thread stack pointer
+ in last user-space context. We hence put the stack pointers in the
+ right place. */
+last_tcb-ksp = last_tcb-active_task-thread.ksp;
+last_tcb-active_task-thread.ksp = last_ksp;
+}
}
static inline void xnarch_finalize_and_switch (xnarchtcb_t *dead_tcb,
