* [Xenomai-core] Xenomai v2.2.3 @ 2006-09-18 7:28 Philippe Gerum 2006-09-18 21:58 ` [Xenomai-help] " Jeff Webb 0 siblings, 1 reply; 11+ messages in thread From: Philippe Gerum @ 2006-09-18 7:28 UTC (permalink / raw) To: xenomai 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] Xenomai v2.2.3 2006-09-18 7:28 [Xenomai-core] Xenomai v2.2.3 Philippe Gerum @ 2006-09-18 21:58 ` Jeff Webb 2006-09-19 22:01 ` Jeff Webb 0 siblings, 1 reply; 11+ messages in thread From: Jeff Webb @ 2006-09-18 21:58 UTC (permalink / raw) To: xenomai 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] Xenomai v2.2.3 2006-09-18 21:58 ` [Xenomai-help] " Jeff Webb @ 2006-09-19 22:01 ` Jeff Webb 2006-09-20 9:24 ` Philippe Gerum 0 siblings, 1 reply; 11+ messages in thread From: Jeff Webb @ 2006-09-19 22:01 UTC (permalink / raw) To: xenomai 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] Xenomai v2.2.3 2006-09-19 22:01 ` Jeff Webb @ 2006-09-20 9:24 ` Philippe Gerum 2006-09-20 14:44 ` Jeff Webb 0 siblings, 1 reply; 11+ messages in thread From: Philippe Gerum @ 2006-09-20 9:24 UTC (permalink / raw) To: Jeff Webb; +Cc: xenomai 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 */ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] Xenomai v2.2.3 2006-09-20 9:24 ` Philippe Gerum @ 2006-09-20 14:44 ` Jeff Webb 2006-09-20 15:22 ` Philippe Gerum 2006-09-20 16:14 ` Philippe Gerum 0 siblings, 2 replies; 11+ messages in thread From: Jeff Webb @ 2006-09-20 14:44 UTC (permalink / raw) To: xenomai 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] Xenomai v2.2.3 2006-09-20 14:44 ` Jeff Webb @ 2006-09-20 15:22 ` Philippe Gerum 2006-09-20 16:14 ` Philippe Gerum 1 sibling, 0 replies; 11+ messages in thread From: Philippe Gerum @ 2006-09-20 15:22 UTC (permalink / raw) To: Jeff Webb; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] Xenomai v2.2.3 2006-09-20 14:44 ` Jeff Webb 2006-09-20 15:22 ` Philippe Gerum @ 2006-09-20 16:14 ` Philippe Gerum 2006-09-20 18:24 ` Jeff Webb 1 sibling, 1 reply; 11+ messages in thread From: Philippe Gerum @ 2006-09-20 16:14 UTC (permalink / raw) To: Jeff Webb; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] Xenomai v2.2.3 2006-09-20 16:14 ` Philippe Gerum @ 2006-09-20 18:24 ` Jeff Webb 2006-09-20 18:33 ` Philippe Gerum 0 siblings, 1 reply; 11+ messages in thread From: Jeff Webb @ 2006-09-20 18:24 UTC (permalink / raw) To: xenomai 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] Xenomai v2.2.3 2006-09-20 18:24 ` Jeff Webb @ 2006-09-20 18:33 ` Philippe Gerum 2006-09-20 20:02 ` Jeff Webb 0 siblings, 1 reply; 11+ messages in thread From: Philippe Gerum @ 2006-09-20 18:33 UTC (permalink / raw) To: Jeff Webb; +Cc: xenomai 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] Xenomai v2.2.3 2006-09-20 18:33 ` Philippe Gerum @ 2006-09-20 20:02 ` Jeff Webb 2006-09-20 20:19 ` Jeff Webb 0 siblings, 1 reply; 11+ messages in thread From: Jeff Webb @ 2006-09-20 20:02 UTC (permalink / raw) To: xenomai 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai-help] Xenomai v2.2.3 2006-09-20 20:02 ` Jeff Webb @ 2006-09-20 20:19 ` Jeff Webb 0 siblings, 0 replies; 11+ messages in thread From: Jeff Webb @ 2006-09-20 20:19 UTC (permalink / raw) To: xenomai 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) ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-09-20 20:19 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-09-18 7:28 [Xenomai-core] Xenomai v2.2.3 Philippe Gerum 2006-09-18 21:58 ` [Xenomai-help] " Jeff Webb 2006-09-19 22:01 ` Jeff Webb 2006-09-20 9:24 ` Philippe Gerum 2006-09-20 14:44 ` Jeff Webb 2006-09-20 15:22 ` Philippe Gerum 2006-09-20 16:14 ` Philippe Gerum 2006-09-20 18:24 ` Jeff Webb 2006-09-20 18:33 ` Philippe Gerum 2006-09-20 20:02 ` Jeff Webb 2006-09-20 20:19 ` Jeff Webb
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.