Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Niklaus Giger wrote: Am Montag, 30. Oktober 2006 08:31 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger: Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum: On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote: Hi My impression from our last discussion was that your toolchain is somehow broken as I was unable to reproduce your problems on (almost) the same hardware I think I really have to reactivate my old Walnut board to have common platform to test with Wolfgang Grandegger. It would make more sense to use the ELDK4 for comparison. I don't think it depends on the hardware. As I forced my son to run on his MacMini (Intel Core Duo) only Linux and no MacOsX (he discovered widelands and was quite happy), I had a platform where I could install the CD with ELDK 4.0, which I had laying around. After some setting up of my environment and tweaking my scripts to work with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my xenomai/configure) I ended --host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set. up with a nice environment and rootfs with much more precompiled programs than I had ever before. Debugging on the platform is now as good as on my PowerBook. My situation is now as follows: - ELDK 4.0 installed on Debian Etch MacMini - Using ELD 4.0 rootfs ppc_4xx - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc (but NOT adding any -mcpu=40x flag to the compiler) The trap 0 in /proc/xenomai/fault seems to count on each invocation of simple 0: 51(Data or instruction access) gdb however no does not show anything abnormal, as it says now This GDB was configured as "ppc-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /bin/simple [Thread debugging using libthread_db enabled] [New Thread 805422032 (LWP 639)] root_thread_init 4[New Thread 805455088 (LWP 642)] Program exited normally. (gdb) quit Though I am still puzzled. Could you please send me your Makefile or the compile command to make "simple", then I would give it a try on my setup. Here are the commands ppc_4xx-gcc -I../.. -I/home/hcu/rootfs/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -I/net/ng/mnt/data.ng/hcu/project/vx_skin -D__XENO__ -g -DVXWORKS-c -o simple.o simple.c ppc_4xx-gcc -o simple simple.o -L/home/hcu/rootfs/usr/xenomai/lib -lpthread -lvxworks Again the same question. What versions of kernel, ADEOS-IPIPE and Xenomai are you using.I have some problems to get the kernel booted with the VxWorks skin emulation. I understood, that I must build the Native and POSIX skin as modules and enable the periodic timer support with a resonable frequency. Wolfgang. > Thanks for your help. > > Will be busy till tomorrow evening. > > Best regards > ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Buildbot finds unresolved symbols `xnarch_atomic_xchg'
On Tue, 2006-10-31 at 07:37 +0100, Niklaus Giger wrote: > Hi > > I see the following failure since revision 1771. e.g. > http://ngiger.dyndns.org/buildbot-full/ppc_f/builds/56/step-mk_kernel/1 > > kernel/built-in.o: In function `xnintr_irq_handler': > intr.c:(.text+0x34334): undefined reference to `xnarch_atomic_xchg' > intr.c:(.text+0x34424): undefined reference to `xnarch_atomic_xchg' > kernel/built-in.o: In function `xnpod_schedule': > (.text+0x38470): undefined reference to `xnarch_atomic_xchg' > kernel/built-in.o: In function `xnpod_schedule_runnable': > (.text+0x39f28): undefined reference to `xnarch_atomic_xchg' > kernel/built-in.o: In function `xnpod_init': > (.text+0x3a770): undefined reference to `xnarch_atomic_xchg' > make: *** [.tmp_vmlinux1] Fehler 1 > Fixed, thanks. > Best regards -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Buildbot finds unresolved symbols `xnarch_atomic_xchg'
Am Dienstag, 31. Oktober 2006 08:51 schrieb Wolfgang Grandegger: > Hi Niklaus, > > Niklaus Giger wrote: > > Hi > > > > I see the following failure since revision 1771. e.g. > > http://ngiger.dyndns.org/buildbot-full/ppc_f/builds/56/step-mk_kernel/1 > > > > kernel/built-in.o: In function `xnintr_irq_handler': > > intr.c:(.text+0x34334): undefined reference to `xnarch_atomic_xchg' > > intr.c:(.text+0x34424): undefined reference to `xnarch_atomic_xchg' > > kernel/built-in.o: In function `xnpod_schedule': > > (.text+0x38470): undefined reference to `xnarch_atomic_xchg' > > kernel/built-in.o: In function `xnpod_schedule_runnable': > > (.text+0x39f28): undefined reference to `xnarch_atomic_xchg' > > kernel/built-in.o: In function `xnpod_init': > > (.text+0x3a770): undefined reference to `xnarch_atomic_xchg' > > make: *** [.tmp_vmlinux1] Fehler 1 > > I lost track somehow. What version of the Linux kernel, ADEOS-IPIPE and > Xenomai are you using? Usually, quite a recent one. My main target is a custom PPC405 target, running U-Boot, Linux 2.6.14, adeos-ipipe-2.6.14-ppc-1.5-01.patch. When I refer to the buildbot (acontinuos integration tool), I mean the the buildbot master, running at http://ngiger.dyndns.org/buildbot/ . It tracks the most recent svn version of the buildbot and builds them for various target (simulator, ppc405 posix, pp405 vxworks, tqm_q with rtnet, ppc60x). Each build contains (if one looks at the different build steps) all the relevant information (kernel, ipipe-version, .config) etc. For details of the above mention build go to: http://ngiger.dyndns.org/buildbot-full/ppc_f/builds/56 and following the different build logs pointed by the stio links. Documentation about the xenomai buildbot can be found at: http://ngiger.dyndns.org/xenomai-data/xeno_buildbot.pdf Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] My work on Xenomai integration to LTTng / LTTV
Jean-Olivier Villemure wrote: > Hello, > > I'm currently working on the integration of Xenomai tracing in LTTng > (Linux Trace Toolkit Next Generation) and the event viewing in LTTV > (Linux Trace Toolkit Viewer). > > At this moment, I 'm tracing events about task handling, period and > soon, mutex and semaphore synchronization. Wow, great news! > > Inserting traqcing points in Xenomai nucleus is not very difficult, my > main work is focus on the controlflow viewer module of LTTV. At this > moment, we can open a trace and view: > - Task state : init, started, running, suspended, overrunning (period > miss) > - Period timer tick for periodic task > - Textual information about the task (name, period, priority, birth) > - Mutex/semaphore owned by specific task > - Soon task waiting on mutex/semaphore > > Look at the screenshot to have a better idea. > > The next step will be to generate some statistics, for this step I will > need your help. As Xenomai users, which kind of stats would you want to > compute? - CPU usage (see /proc/xenomai/stat for average numbers, but we should now be able to precisely calculate them for a specific period) - Waiting times after activation (maybe one can define deadlines later and verify them) - Number of preemptions per second or whatever while a task is runnable - Number of blockades a task faces due to unavailable resources (mutexes, semaphores, etc.) ...just to through some first ideas in. > > After that, I'll study the possibilities of simulating an execution > trace from an existing trace by modifying some parameters (period > length, ...) > > Any ideas are welcome! So you have an integrated I-pipe+LTTng patch which is able to record events under any context and push them to Linux non-RT user-space, right? How does this work, what impact does it have (also compared to the I-pipe tracer, which is not light-weight)? And, most important, when will we be able to see some code (ipipe add-on patch)? Would be good to assess how this could be integrated on the long term into I-pipe/Xenomai, at least until required LTTng parts become mainstream. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Am Dienstag, 31. Oktober 2006 09:14 schrieb Wolfgang Grandegger: > Niklaus Giger wrote: > > Am Montag, 30. Oktober 2006 08:31 schrieb Wolfgang Grandegger: > >> Niklaus Giger wrote: > >>> Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger: > Niklaus Giger wrote: > > Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger: > >> Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum: > >>> On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote: > Hi > > My impression from our last discussion was that your toolchain is > somehow broken as I was unable to reproduce your problems on (almost) > the same hardware > > > I think I really have to reactivate my old Walnut board to have > > common platform to test with Wolfgang Grandegger. > > It would make more sense to use the ELDK4 for comparison. I don't > think it depends on the hardware. > >>> > >>> As I forced my son to run on his MacMini (Intel Core Duo) only Linux > >>> and no MacOsX (he discovered widelands and was quite happy), I had a > >>> platform where I could install the CD with ELDK 4.0, which I had laying > >>> around. > >>> > >>> After some setting up of my environment and tweaking my scripts to work > >>> with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my > >>> xenomai/configure) I ended > >> > >> --host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set. > >> > >>> up with a nice environment and rootfs with much more precompiled > >>> programs than I had ever before. Debugging on the platform is now as > >>> good as on my PowerBook. > >>> > >>> My situation is now as follows: > >>> - ELDK 4.0 installed on Debian Etch MacMini > >>> - Using ELD 4.0 rootfs ppc_4xx > >>> - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc > >>>(but NOT adding any -mcpu=40x flag to the compiler) > >>> > >>> The trap 0 in /proc/xenomai/fault seems to count on each invocation of > >>> simple 0: 51(Data or instruction access) > >>> gdb however no does not show anything abnormal, as it says now > >>> > This GDB was configured as "ppc-linux"...Using host libthread_db > library "/lib/tls/libthread_db.so.1". > > (gdb) run > Starting program: /bin/simple > [Thread debugging using libthread_db enabled] > [New Thread 805422032 (LWP 639)] > root_thread_init 4[New Thread 805455088 (LWP 642)] > > Program exited normally. > (gdb) quit > >>> > >>> Though I am still puzzled. > >> > >> Could you please send me your Makefile or the compile command to make > >> "simple", then I would give it a try on my setup. > > > > Here are the commands > > ppc_4xx-gcc -I../.. -I/home/hcu/rootfs/usr/xenomai/include -D_GNU_SOURCE > > -D_REENTRANT -I/net/ng/mnt/data.ng/hcu/project/vx_skin -D__XENO__ -g > > -DVXWORKS-c -o simple.o simple.c > > ppc_4xx-gcc -o simple > > simple.o -L/home/hcu/rootfs/usr/xenomai/lib -lpthread -lvxworks > > Again the same question. What versions of kernel, ADEOS-IPIPE and > Xenomai are you using.I have some problems to get the kernel booted with > the VxWorks skin emulation. I understood, that I must build the Native > and POSIX skin as modules and enable the periodic timer support with a > resonable frequency. I used revision 1747 of the xenomai trunk, linux 2.4.17 + some small patches (attached) for my system, the attached .config, adeos-ipipe-2.6.14-ppc-1.5-01.patch. I have vxworks built-in to enforce that the timers get initialized into the periodic mode. Best regards -- Niklaus Giger .config.bz2 Description: BZip2 compressed data hcu3-2.6.14.patch.bz2 Description: BZip2 compressed data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Niklaus Giger wrote: Am Dienstag, 31. Oktober 2006 09:14 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Montag, 30. Oktober 2006 08:31 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger: Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum: On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote: Hi My impression from our last discussion was that your toolchain is somehow broken as I was unable to reproduce your problems on (almost) the same hardware I think I really have to reactivate my old Walnut board to have common platform to test with Wolfgang Grandegger. It would make more sense to use the ELDK4 for comparison. I don't think it depends on the hardware. As I forced my son to run on his MacMini (Intel Core Duo) only Linux and no MacOsX (he discovered widelands and was quite happy), I had a platform where I could install the CD with ELDK 4.0, which I had laying around. After some setting up of my environment and tweaking my scripts to work with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my xenomai/configure) I ended --host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set. up with a nice environment and rootfs with much more precompiled programs than I had ever before. Debugging on the platform is now as good as on my PowerBook. My situation is now as follows: - ELDK 4.0 installed on Debian Etch MacMini - Using ELD 4.0 rootfs ppc_4xx - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc (but NOT adding any -mcpu=40x flag to the compiler) The trap 0 in /proc/xenomai/fault seems to count on each invocation of simple 0: 51(Data or instruction access) gdb however no does not show anything abnormal, as it says now This GDB was configured as "ppc-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /bin/simple [Thread debugging using libthread_db enabled] [New Thread 805422032 (LWP 639)] root_thread_init 4[New Thread 805455088 (LWP 642)] Program exited normally. (gdb) quit Though I am still puzzled. Could you please send me your Makefile or the compile command to make "simple", then I would give it a try on my setup. Here are the commands ppc_4xx-gcc -I../.. -I/home/hcu/rootfs/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -I/net/ng/mnt/data.ng/hcu/project/vx_skin -D__XENO__ -g -DVXWORKS-c -o simple.o simple.c ppc_4xx-gcc -o simple simple.o -L/home/hcu/rootfs/usr/xenomai/lib -lpthread -lvxworks Again the same question. What versions of kernel, ADEOS-IPIPE and Xenomai are you using.I have some problems to get the kernel booted with the VxWorks skin emulation. I understood, that I must build the Native and POSIX skin as modules and enable the periodic timer support with a resonable frequency. I used revision 1747 of the xenomai trunk, linux 2.4.17 + some small patches ^^ I think you mean linux 2.4.14 here. (attached) for my system, the attached .config, adeos-ipipe-2.6.14-ppc-1.5-01.patch. I have vxworks built-in to enforce that the timers get initialized into the periodic mode. OK, I will use the same setup for my test. Wolfgang. Best regards ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Am Dienstag, 31. Oktober 2006 20:02 schrieb Wolfgang Grandegger: > > I used revision 1747 of the xenomai trunk, linux 2.4.17 + some small > > patches > > ^^ > I think you mean linux 2.4.14 here. Sorry. My mistake: Linux 2.6.14 to match adeos-ipipe-2.6.14-ppc-1.5-01.patch. -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Niklaus Giger wrote: Am Dienstag, 31. Oktober 2006 09:14 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Montag, 30. Oktober 2006 08:31 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger: Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum: On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote: Hi My impression from our last discussion was that your toolchain is somehow broken as I was unable to reproduce your problems on (almost) the same hardware I think I really have to reactivate my old Walnut board to have common platform to test with Wolfgang Grandegger. It would make more sense to use the ELDK4 for comparison. I don't think it depends on the hardware. As I forced my son to run on his MacMini (Intel Core Duo) only Linux and no MacOsX (he discovered widelands and was quite happy), I had a platform where I could install the CD with ELDK 4.0, which I had laying around. After some setting up of my environment and tweaking my scripts to work with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my xenomai/configure) I ended --host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set. up with a nice environment and rootfs with much more precompiled programs than I had ever before. Debugging on the platform is now as good as on my PowerBook. My situation is now as follows: - ELDK 4.0 installed on Debian Etch MacMini - Using ELD 4.0 rootfs ppc_4xx - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc (but NOT adding any -mcpu=40x flag to the compiler) The trap 0 in /proc/xenomai/fault seems to count on each invocation of simple 0: 51(Data or instruction access) gdb however no does not show anything abnormal, as it says now This GDB was configured as "ppc-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /bin/simple [Thread debugging using libthread_db enabled] [New Thread 805422032 (LWP 639)] root_thread_init 4[New Thread 805455088 (LWP 642)] Program exited normally. (gdb) quit Though I am still puzzled. Could you please send me your Makefile or the compile command to make "simple", then I would give it a try on my setup. Here are the commands ppc_4xx-gcc -I../.. -I/home/hcu/rootfs/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -I/net/ng/mnt/data.ng/hcu/project/vx_skin -D__XENO__ -g -DVXWORKS-c -o simple.o simple.c ppc_4xx-gcc -o simple simple.o -L/home/hcu/rootfs/usr/xenomai/lib -lpthread -lvxworks Again the same question. What versions of kernel, ADEOS-IPIPE and Xenomai are you using.I have some problems to get the kernel booted with the VxWorks skin emulation. I understood, that I must build the Native and POSIX skin as modules and enable the periodic timer support with a resonable frequency. I used revision 1747 of the xenomai trunk, linux 2.4.17 + some small patches (attached) for my system, the attached .config, adeos-ipipe-2.6.14-ppc-1.5-01.patch. I have vxworks built-in to enforce that the timers get initialized into the periodic mode. OK, with a similar setup I get the same results as you have seen on your (son's) MacMini. I have attached the output. Wolfgang. sh-3.00# export LD_LIBRARY_PATH=/home/wolf/xenomai/lib bash-3.00# ./simple root_thread_init 3 bash-3.00# cat /proc/xenomai/faults TRAP CPU0 0:1(Data or instruction access) 1:0(Alignment) 2:0(Altivec unavailable) 3:0(Program check exception) 4:0(Machine check exception) 5:0(Unknown) 6:0(Instruction breakpoint) 7:0(Run mode exception) 8:0(Single-step exception) 9:0(Non-recoverable exception) 10:0(Software emulation) 11:0(Debug) 12:0(SPE) 13:0(Altivec assist) bash-3.00# ./simple root_thread_init 3 bash-3.00# cat /proc/xenomai/faults TRAP CPU0 0:2(Data or instruction access) 1:0(Alignment) 2:0(Altivec unavailable) 3:0(Program check exception) 4:0(Machine check exception) 5:0(Unknown) 6:0(Instruction breakpoint) 7:0(Run mode exception) 8:0(Single-step exception) 9:0(Non-recoverable exception) 10:0(Software emulation) 11:0(Debug) 12:0(SPE) 13:0(Altivec assist) bash-3.00# gdb simple GNU gdb Red Hat Linux (6.3.0.0-1.21_1rh) 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 i
Re: [Xenomai-core] My work on Xenomai integration to LTTng / LTTV
On Tue, 2006-10-31 at 18:34 +0100, Jan Kiszka wrote: > Jean-Olivier Villemure wrote: > > > > The next step will be to generate some statistics, for this step I will > > need your help. As Xenomai users, which kind of stats would you want to > > compute? > > - CPU usage (see /proc/xenomai/stat for average numbers, but we should >now be able to precisely calculate them for a specific period) > - Waiting times after activation (maybe one can define deadlines later >and verify them) > - Number of preemptions per second or whatever while a task is runnable > - Number of blockades a task faces due to unavailable resources >(mutexes, semaphores, etc.) - Average number of elements linked to the readyq per second (some kind of loadavg for us, i.e. answers the question "should the user switch to the scalable scheduler?") - Average number of outstanding timers per second (i.e. answers the question "should the user switch to the binary heap-based timer management?"). - Total number of timers missing their wakeup date from more than a given threshold. - Pressure on the system heap (average and max, probably). - Transfer rate on message pipes (i.e. nucleus/pipe.c); at some point, it would be interesting to extend this to skins exposing data channels (e.g. native API's queues, POSIX mqueues). -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
