[Xenomai-core] Xenomai v2.2.3

[Xenomai-core] Xenomai v2.2.3

[Philippe Gerum]

Here is the third maintenance release for the v2.2.x branch.  Short
log follows:

	[nucleus]

	* Use per-task event filter implemented by recent Adeos
	patches, to reduce the overhead induced by event pipelining.

	* Support partial buffer reading from the message pipe device
	endpoint.

	* Fix spurious wakeup triggered by the periodic handler for
	threads blocked on a resource.

	* x86: Make sure to always restore the FPU context of the root
	thread consistently with the TS bit state.

	[hal]

	* Toggle IRQ_DISABLED appropriately when enabling/disabling an
	interrupt channel.

	[posix]

	* Make pthread_join() usable from module init/cleanup routines.

	[native]

	* Optimize data streaming mode.

	[rtai]

	* Improve compliance of rtf_get().

	* Fix memory leak in rtf_destroy().

See the ChangeLog for details.

http://download.gna.org/xenomai/stable/xenomai-2.2.3.tar.bz2

-- 
Philippe.

Re: [Xenomai-help] Xenomai v2.2.3

[Jeff Webb]

Philippe Gerum wrote:
> Here is the third maintenance release for the v2.2.x branch.
> ...

This release works fine on my 2.6 kernel x86 machine, with the exception of the FPU problems noted elsewhere.

I have the following problems with my 2.4 kernel x86 machine:
  * The latency and switchtest test programs yield segmentation faults.
  * My own user-space test programs seg fault.

Things that work:
  * The kernel boots and runs fine.
  * xeno_native, _posix, _rtai all insert and remove without problems.
  * Some simple kernel module test programs work fine.

I am using the same config as I was for 2.2.2 (which worked fine), but I am running a slightly newer kernel version (2.4.33.3 as opposed to 2.4.32).

I hope this helps,

-Jeff

Output of latency/run:
----------------------------------
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
/usr/xenomai/bin/xeno-load: line 249:  5358 Segmentation fault      $suflag $* $cmdargs


Output of switchtest/run:
-----------------------------

*
*
* Type ^C to stop this application.
*
*
== Testing FPU check routines...
r0: 1 != 2
r1: 1 != 2
r2: 1 != 2
r3: 1 != 2
r4: 1 != 2
r5: 1 != 2
r6: 1 != 2
r7: 1 != 2
== FPU check routines: OK.
/usr/xenomai/bin/xeno-load: line 249:  5273 Segmentation fault      $suflag $* $cmdargs
xeno_switchtest: Device or resource busy


-Jeff

Re: [Xenomai-help] Xenomai v2.2.3

[Jeff Webb]

Jeff Webb wrote:
> Philippe Gerum wrote:
>> Here is the third maintenance release for the v2.2.x branch.
>> ...
> 
> This release works fine on my 2.6 kernel x86 machine, with the exception 
> of the FPU problems noted elsewhere.
> 
> I have the following problems with my 2.4 kernel x86 machine:
>  * The latency and switchtest test programs yield segmentation faults.
>  * My own user-space test programs seg fault.
> 
> Things that work:
>  * The kernel boots and runs fine.
>  * xeno_native, _posix, _rtai all insert and remove without problems.
>  * Some simple kernel module test programs work fine.
> 
> I am using the same config as I was for 2.2.2 (which worked fine), but I 
> am running a slightly newer kernel version (2.4.33.3 as opposed to 2.4.32).

I was able to build a working xenomai-2.2.3 by using linux-2.4.32 and adeos-ipipe-2.4.32-i386-1.2-07.patch.  The latency and switchtest programs seem to work now.  My problematic build used linux-2.4.33.3 and the adeos-ipipe-2.4.33-i386-1.3-00.patch.  I used the same kernel config for both builds.  

So, does this mean the problem is with the ipipe patch?

This machine is an AMD Athlon(tm) XP 3200+, gcc version 3.3.2, Fedora Core 1.

-Jeff
 

Re: [Xenomai-help] Xenomai v2.2.3

[Philippe Gerum]

On Tue, 2006-09-19 at 17:01 -0500, Jeff Webb wrote:
> Jeff Webb wrote:
> > Philippe Gerum wrote:
> >> Here is the third maintenance release for the v2.2.x branch.
> >> ...
> > 
> > This release works fine on my 2.6 kernel x86 machine, with the exception 
> > of the FPU problems noted elsewhere.
> > 
> > I have the following problems with my 2.4 kernel x86 machine:
> >  * The latency and switchtest test programs yield segmentation faults.
> >  * My own user-space test programs seg fault.
> > 
> > Things that work:
> >  * The kernel boots and runs fine.
> >  * xeno_native, _posix, _rtai all insert and remove without problems.
> >  * Some simple kernel module test programs work fine.
> > 
> > I am using the same config as I was for 2.2.2 (which worked fine), but I 
> > am running a slightly newer kernel version (2.4.33.3 as opposed to 2.4.32).
> 
> I was able to build a working xenomai-2.2.3 by using linux-2.4.32 and adeos-ipipe-2.4.32-i386-1.2-07.patch.  The latency and switchtest programs seem to work now.  My problematic build used linux-2.4.33.3 and the adeos-ipipe-2.4.33-i386-1.3-00.patch.  I used the same kernel config for both builds.  
> 
> So, does this mean the problem is with the ipipe patch?
> 

The problem also occurs with older patches, and it looks like extremely
volatile, depending on various parameters, including the CPU
generation/brand, so I tend to think that this issue is not directly
related to the recent Adeos changes, but might trigger more easily with
the latest patch on your box. Could you try the following patch against
vanilla 2.2.3, on all your failing configs so far, and let us know of
the outcome? TIA,

--- include/asm-i386/system.h	(revision 1644)
+++ include/asm-i386/system.h	(working copy)
@@ -68,7 +68,6 @@
 
     /* FPU context bits for root thread. */
     unsigned is_root: 1;
-    unsigned cr0_ts: 1;
     unsigned ts_usedfpu: 1;
 
 } xnarchtcb_t;
@@ -142,7 +141,6 @@
 {
     /* Remember the preempted Linux task pointer. */
     rootcb->user_task = rootcb->active_task = current;
-    rootcb->cr0_ts = (read_cr0() & 8) != 0;
     rootcb->ts_usedfpu = wrap_test_fpu_used(current) != 0;
     /* So that xnarch_save_fpu() will operate on the right FPU area. */
     rootcb->fpup = &rootcb->user_task->thread.i387;
@@ -377,119 +375,96 @@
 static inline void xnarch_save_fpu (xnarchtcb_t *tcb)
 
 {
-    struct task_struct *task = tcb->user_task;
-    
-    if (!tcb->is_root)
-	{
-        if (task)
-	    {	
-            if (!wrap_test_fpu_used(task))
-		return;
+	struct task_struct *task = tcb->user_task;
 
-	    /* Tell Linux that we already saved the state of the FPU
-	       hardware of this task. */
-	    wrap_clear_fpu_used(task);
-	    }
-	}
-    else
-	{
-	    /* Do not save root context FPU if cr0 bit ts is armed . */
-	    if (tcb->cr0_ts)
-		return;
+	if (task) {
+		if (!wrap_test_fpu_used(task))
+			return;
 
-	    if (tcb->ts_usedfpu)
+		/* Tell Linux that we already saved the state of the FPU
+		   hardware of this task. */
 		wrap_clear_fpu_used(task);
 	}
 
+	clts();
 
-    clts();
-    
-    if (cpu_has_fxsr)
-        __asm__ __volatile__ ("fxsave %0; fnclex" : "=m" (*tcb->fpup));
-    else
-        __asm__ __volatile__ ("fnsave %0; fwait" : "=m" (*tcb->fpup));
+	if (cpu_has_fxsr)
+		__asm__ __volatile__("fxsave %0; fnclex":"=m"(*tcb->fpup));
+	else
+      __asm__ __volatile__("fnsave %0; fwait":"=m"(*tcb->fpup));
 }
 
 static inline void xnarch_restore_fpu (xnarchtcb_t *tcb)
 
 {
-    struct task_struct *task = tcb->user_task;
+	struct task_struct *task = tcb->user_task;
 
-    if (!tcb->is_root)
-	{
-	if (task)
-	    {
-	    if (!xnarch_fpu_init_p(task))
-		{
-		stts();
-		return;	/* Uninit fpu area -- do not restore. */
+	if (!tcb->is_root) {
+		if (task) {
+			if (!xnarch_fpu_init_p(task)) {
+				stts();
+				return;	/* Uninit fpu area -- do not restore. */
+			}
+
+			/* Tell Linux that this task has altered the state of
+			 * the FPU hardware. */
+			wrap_set_fpu_used(task);
 		}
-		    
-	    /* Tell Linux that this task has altered the state of
-	     * the FPU hardware. */
-	    wrap_set_fpu_used(task);
-	    }
-	}
-    else
-	{
-	/* Restore state of ts bit if armed. */
-	if (tcb->cr0_ts)
-	    {
-	    stts();
-	    return;
-	    }
+	} else {
+		/* Restore state of FPU if TS_USEFPU bit was armed. */
+		if (!tcb->ts_usedfpu) {
+			stts();
+			return;
+		}
 
-	if (tcb->ts_usedfpu)
-	    wrap_set_fpu_used(task);
+		wrap_set_fpu_used(task);
 	}
 
-    /* Restore the FPU hardware with valid fp registers from a
-       user-space or kernel thread. */
-    clts();
+	/* Restore the FPU hardware with valid fp registers from a
+	   user-space or kernel thread. */
+	clts();
 
-    if (cpu_has_fxsr)
-        __asm__ __volatile__ ("fxrstor %0": /* no output */ : "m" (*tcb->fpup));
-    else
-        __asm__ __volatile__ ("frstor %0": /* no output */ : "m" (*tcb->fpup));
+	if (cpu_has_fxsr)
+		__asm__ __volatile__("fxrstor %0": /* no output */
+				     :"m"(*tcb->fpup));
+	else
+      __asm__ __volatile__("frstor %0": /* no output */ :"m"(*tcb->
+	    fpup));
 }
 
 static inline void xnarch_enable_fpu(xnarchtcb_t *tcb)
 
 {
-    struct task_struct *task = tcb->user_task;
+	struct task_struct *task = tcb->user_task;
 
-    if (!tcb->is_root)
-	{
-	if (task)
-	    {
-	    if (!xnarch_fpu_init_p(task))
-		return;
+	if (!tcb->is_root) {
+		if (task) {
+			if (!xnarch_fpu_init_p(task))
+				return;
 
-	    /* If "task" switched while in Linux domain, its FPU
-	     * context may have been overriden, restore it. */
-	    if (!wrap_test_fpu_used(task))
-		{
+			/* If "task" switched while in Linux domain, its FPU
+			 * context may have been overriden, restore it. */
+			if (!wrap_test_fpu_used(task)) {
+				xnarch_restore_fpu(tcb);
+				return;
+			}
+		}
+	} else {
+		if (!tcb->ts_usedfpu)
+			return;
+
 		xnarch_restore_fpu(tcb);
 		return;
-		}
-	    }
 	}
-    else
-	{
-	if (tcb->cr0_ts)
-	    return;
 
-	xnarch_restore_fpu(tcb);
-	return;
-	}
+	clts();
 
-    clts();
-
-    if (!cpu_has_fxsr && task)
-        /* fnsave, called by switch_to, initialized the FPU state, so that on
-           cpus prior to PII (i.e. without fxsr), we need to restore the saved
-           state. */
-        __asm__ __volatile__ ("frstor %0": /* no output */ : "m" (*tcb->fpup));
+	if (!cpu_has_fxsr && task)
+		/* fnsave, called by switch_to, initialized the FPU state, so that on
+		   cpus prior to PII (i.e. without fxsr), we need to restore the saved
+		   state. */
+		__asm__ __volatile__("frstor %0": /* no output */
+				     :"m"(*tcb->fpup));
 }
 
 #else /* !CONFIG_XENO_HW_FPU */

Re: [Xenomai-help] Xenomai v2.2.3

[Jeff Webb]

Philippe Gerum wrote:
> On Tue, 2006-09-19 at 17:01 -0500, Jeff Webb wrote:
>> Jeff Webb wrote:
>>> Philippe Gerum wrote:
>>>> Here is the third maintenance release for the v2.2.x branch.
>>>> ...
>>> This release works fine on my 2.6 kernel x86 machine, with the exception 
>>> of the FPU problems noted elsewhere.
>>>
>>> I have the following problems with my 2.4 kernel x86 machine:
>>>  * The latency and switchtest test programs yield segmentation faults.
>>>  * My own user-space test programs seg fault.
>>>
>>> Things that work:
>>>  * The kernel boots and runs fine.
>>>  * xeno_native, _posix, _rtai all insert and remove without problems.
>>>  * Some simple kernel module test programs work fine.
>>>
>>> I am using the same config as I was for 2.2.2 (which worked fine), but I 
>>> am running a slightly newer kernel version (2.4.33.3 as opposed to 2.4.32).
>> I was able to build a working xenomai-2.2.3 by using linux-2.4.32 and adeos-ipipe-2.4.32-i386-1.2-07.patch.  The latency and switchtest programs seem to work now.  My problematic build used linux-2.4.33.3 and the adeos-ipipe-2.4.33-i386-1.3-00.patch.  I used the same kernel config for both builds.  
>>
>> So, does this mean the problem is with the ipipe patch?
>>
> 
> The problem also occurs with older patches, and it looks like extremely
> volatile, depending on various parameters, including the CPU
> generation/brand, so I tend to think that this issue is not directly
> related to the recent Adeos changes, but might trigger more easily with
> the latest patch on your box. Could you try the following patch against
> vanilla 2.2.3, on all your failing configs so far, and let us know of
> the outcome? TIA,

Sorry for not being more clear.  This appears to be a separate problem from the FPU issue.  At least the symptoms are different...  I have only seen this problem on my xenomai-2.2.3/linux-2.4.33.3 (ipipe-1.3) build.  The symptom is that xeno-load gives a segmentation fault in the latency program (switchtest suffers the exact same problem).  A couple of my own userspace RT test programs seg fault as well.  Look at the latency output near the bottom of my original email to see what I mean:

  https://mail.gna.org/public/xenomai-help/2006-09/msg00152.html

Switching to xenomai-2.2.3/linux-2.4.32 (ipipe-1.2) fixed this problem.  Do you agree that this appears to be a different bug?  Sorry for the confusion... I am trying to debug two or three different problems at the same time.  Maybe I should have waited until the FPU bug was solved to report this.

I have not experienced the FPU-related switchtest error on my 2.4 machine.  My 2.6 machine exhibits the problem, so I will certainly test your patch on that machine to see the effect.

Thanks!

-Jeff

Re: [Xenomai-help] Xenomai v2.2.3

[Philippe Gerum]

On Wed, 2006-09-20 at 09:44 -0500, Jeff Webb wrote:
> Philippe Gerum wrote:
> > On Tue, 2006-09-19 at 17:01 -0500, Jeff Webb wrote:
> >> Jeff Webb wrote:
> >>> Philippe Gerum wrote:
> >>>> Here is the third maintenance release for the v2.2.x branch.
> >>>> ...
> >>> This release works fine on my 2.6 kernel x86 machine, with the exception 
> >>> of the FPU problems noted elsewhere.
> >>>
> >>> I have the following problems with my 2.4 kernel x86 machine:
> >>>  * The latency and switchtest test programs yield segmentation faults.
> >>>  * My own user-space test programs seg fault.
> >>>
> >>> Things that work:
> >>>  * The kernel boots and runs fine.
> >>>  * xeno_native, _posix, _rtai all insert and remove without problems.
> >>>  * Some simple kernel module test programs work fine.
> >>>
> >>> I am using the same config as I was for 2.2.2 (which worked fine), but I 
> >>> am running a slightly newer kernel version (2.4.33.3 as opposed to 2.4.32).
> >> I was able to build a working xenomai-2.2.3 by using linux-2.4.32 and adeos-ipipe-2.4.32-i386-1.2-07.patch.  The latency and switchtest programs seem to work now.  My problematic build used linux-2.4.33.3 and the adeos-ipipe-2.4.33-i386-1.3-00.patch.  I used the same kernel config for both builds.  
> >>
> >> So, does this mean the problem is with the ipipe patch?
> >>
> > 
> > The problem also occurs with older patches, and it looks like extremely
> > volatile, depending on various parameters, including the CPU
> > generation/brand, so I tend to think that this issue is not directly
> > related to the recent Adeos changes, but might trigger more easily with
> > the latest patch on your box. Could you try the following patch against
> > vanilla 2.2.3, on all your failing configs so far, and let us know of
> > the outcome? TIA,
> 
> Sorry for not being more clear.  This appears to be a separate problem from the FPU issue.  At least the symptoms are different...  I have only seen this problem on my xenomai-2.2.3/linux-2.4.33.3 (ipipe-1.3) build.  The symptom is that xeno-load gives a segmentation fault in the latency program (switchtest suffers the exact same problem).  A couple of my own userspace RT test programs seg fault as well.  Look at the latency output near the bottom of my original email to see what I mean:
> 
>   https://mail.gna.org/public/xenomai-help/2006-09/msg00152.html
> 
> Switching to xenomai-2.2.3/linux-2.4.32 (ipipe-1.2) fixed this problem.
> Do you agree that this appears to be a different bug?

Ah, ok. Yes, clearly, this sounds different.

>   Sorry for the confusion... I am trying to debug two or three different problems at the same time. 
> Maybe I should have waited until the FPU bug was solved to report this.

No problem, I mistakenly made the connection between both issues. I'm
going to fire up a test box with 2.4.33.3 over Adeos 1-3.00 + v2.2.3 and
see what happens. More later.

> 
> I have not experienced the FPU-related switchtest error on my 2.4 machine.
> My 2.6 machine exhibits the problem, so I will certainly test your patch on that machine to see the effect.
> 

TIA,

> Thanks!
> 
> -Jeff
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Xenomai v2.2.3

[Philippe Gerum]

On Wed, 2006-09-20 at 09:44 -0500, Jeff Webb wrote:

> Switching to xenomai-2.2.3/linux-2.4.32 (ipipe-1.2) fixed this problem.

Could you try running 2.2.3 stock + fpu fix patch over 2.4.33.3/1.3-00,
and 2.2.3 stock over 2.4.33.3/1.2-08 ? I'm trying to find out if there
is a dependency on the kernel version, and/or the Adeos release, and/or
the fpu issue, for the segfault bug. TIA,

-- 
Philippe.

Re: [Xenomai-help] Xenomai v2.2.3

[Jeff Webb]

Philippe Gerum wrote:
> On Wed, 2006-09-20 at 09:44 -0500, Jeff Webb wrote:
> 
>> Switching to xenomai-2.2.3/linux-2.4.32 (ipipe-1.2) fixed this problem.
> 
> Could you try running 2.2.3 stock + fpu fix patch over 2.4.33.3/1.3-00,
> and 2.2.3 stock over 2.4.33.3/1.2-08 ? I'm trying to find out if there
> is a dependency on the kernel version, and/or the Adeos release, and/or
> the fpu issue, for the segfault bug. TIA,

I just tested two more builds.  Both of them have the segfault bug.  Here is a summary of the results thus far:

Latency test works:
  linux-2.4.32, adeos-ipipe-2.4.32-i386-1.2-07.patch

Latency test segfaults:
  linux-2.4.33.3, adeos-ipipe-2.4.33-i386-1.3-00.patch
  linux-2.4.33.3, adeos-ipipe-2.4.33-i386-1.2-07.patch
  linux-2.4.33.3 (+ FPU fix patch), adeos-ipipe-2.4.33-i386-1.3-00.patch

All of these are with xenomai-2.2.3.  The last one has the FPU fix patch applied.  So, it appears to be something in the newer kernel version...

Thanks,

Jeff

Re: [Xenomai-help] Xenomai v2.2.3

[Philippe Gerum]

On Wed, 2006-09-20 at 13:24 -0500, Jeff Webb wrote:
> Philippe Gerum wrote:
> > On Wed, 2006-09-20 at 09:44 -0500, Jeff Webb wrote:
> > 
> >> Switching to xenomai-2.2.3/linux-2.4.32 (ipipe-1.2) fixed this problem.
> > 
> > Could you try running 2.2.3 stock + fpu fix patch over 2.4.33.3/1.3-00,
> > and 2.2.3 stock over 2.4.33.3/1.2-08 ? I'm trying to find out if there
> > is a dependency on the kernel version, and/or the Adeos release, and/or
> > the fpu issue, for the segfault bug. TIA,
> 
> I just tested two more builds.  Both of them have the segfault bug.  Here is a summary of the results thus far:
> 
> Latency test works:
>   linux-2.4.32, adeos-ipipe-2.4.32-i386-1.2-07.patch
> 
> Latency test segfaults:
>   linux-2.4.33.3, adeos-ipipe-2.4.33-i386-1.3-00.patch
>   linux-2.4.33.3, adeos-ipipe-2.4.33-i386-1.2-07.patch
>   linux-2.4.33.3 (+ FPU fix patch), adeos-ipipe-2.4.33-i386-1.3-00.patch
> 
> All of these are with xenomai-2.2.3.  The last one has the FPU fix patch applied.  So, it appears to be something in the newer kernel version...
> 

Ok, that helps thanks. Now, running the latency test over GDB instead of
using the "run" script would likely give us a backtrace for the
segfault. I'd be interested to know where the latency application is
sent the fault signal. E.g.

modprobe xeno_nucleus
modprobe xeno_native
(if needed)

then,

cd /usr/xenomai/testsuite/latency
gdb latency
r
...(SIGSEGV)...
bt

TIA,

> Thanks,
> 
> Jeff
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Xenomai v2.2.3

[Jeff Webb]

Philippe Gerum wrote:
> Ok, that helps thanks. Now, running the latency test over GDB instead of
> using the "run" script would likely give us a backtrace for the
> segfault. I'd be interested to know where the latency application is
> sent the fault signal. E.g.
> 
> modprobe xeno_nucleus
> modprobe xeno_native
> (if needed)
> 
> then,
> 
> cd /usr/xenomai/testsuite/latency
> gdb latency
> r
> ...(SIGSEGV)...
> bt

If I just run latency, I get the segfault:

[root@domain.hid webb-ja]# cd /usr/xenomai/testsuite/latency/
[root@domain.hid latency]# /sbin/modprobe xeno_native
[root@domain.hid latency]# ./latency
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
Segmentation fault


If I try to run gdb on it, it just hangs when I type the "r" command:

[root@domain.hid webb-ja]# cd /usr/xenomai/testsuite/latency/
[root@domain.hid latency]# /sbin/modprobe xeno_native
[root@domain.hid latency]# gdb latency
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
Copyright 2003 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 "i386-redhat-linux-gnu"...
(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) r
Starting program: /usr/xenomai-2.2.3/testsuite/latency/latency
(no debugging symbols found)...[Thread debugging using libthread_db enabled]
Error while reading shared library symbols:
Cannot find new threads: generic error
(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...


At this point, the terminal is locked, and I have to use kill -9 from another terminal.  I did some googling on the error message and found this thread:

http://sources.redhat.com/ml/gdb/2005-04/msg00201.html

Any hints on what I am doing wrong?  Sorry, if I am doing something silly and don't realize it.

Thanks,

Jeff

Re: [Xenomai-help] Xenomai v2.2.3

[Jeff Webb]

Jeff Webb wrote:
> Philippe Gerum wrote:
>>
>> cd /usr/xenomai/testsuite/latency
>> gdb latency
>> r
>> ...(SIGSEGV)...
>> bt
> 
> If I try to run gdb on it, it just hangs when I type the "r" command:
> 
> [root@domain.hid webb-ja]# cd /usr/xenomai/testsuite/latency/
> [root@domain.hid latency]# /sbin/modprobe xeno_native
> [root@domain.hid latency]# gdb latency
> GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
> Copyright 2003 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 "i386-redhat-linux-gnu"...
> (no debugging symbols found)...Using host libthread_db library 
> "/lib/tls/libthread_db.so.1".
> (gdb) r
> Starting program: /usr/xenomai-2.2.3/testsuite/latency/latency
> (no debugging symbols found)...[Thread debugging using libthread_db 
> enabled]
> Error while reading shared library symbols:
> Cannot find new threads: generic error
> (no debugging symbols found)...
> (no debugging symbols found)...(no debugging symbols found)...

With one of my working xenomai kernels, the above steps seem to work, so maybe the above symptom is part of the bug.  My results for a working kernel are shown below:

-Jeff


[root@domain.hid webb-ja]# cd /usr/xenomai/testsuite/latency/
[root@domain.hid latency]# gdb latency
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
Copyright 2003 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 "i386-redhat-linux-gnu"...
(no debugging symbols found)...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) r
Starting program: /usr/xenomai-2.2.3/testsuite/latency/latency
(no debugging symbols found)...[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 5239)]
(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
[New Thread 32769 (LWP 5240)]
[New Thread 16386 (LWP 5241)]
warming up...
[New Thread 32771 (LWP 5242)]
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
RTD|      -1.782|      -1.154|       4.307|       0|      -1.782|       4.307
RTD|      -1.933|      -1.158|       4.157|       0|      -1.933|       4.307
RTD|      -1.924|      -1.223|       4.497|       0|      -1.933|       4.497
RTD|      -2.014|      -1.206|       4.438|       0|      -2.014|       4.497

Program received signal SIGINT, Interrupt.
[Switching to Thread 32771 (LWP 5242)]
0x0804b555 in rt_task_wait_period ()
(gdb) bt
#0  0x0804b555 in rt_task_wait_period ()
#1  0x08049f7c in latency ()
#2  0x0804b233 in rt_task_trampoline ()
#3  0x48a3bdb2 in pthread_start_thread () from /lib/i686/libpthread.so.0
#4  0x48a3bf45 in pthread_start_thread_event () from /lib/i686/libpthread.so.0
#5  0x488a97fa in clone () from /lib/i686/libc.so.6
(gdb)