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] 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 ^^ 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 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 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] Bug in taskSuspend for user mode vxworks
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 Thanks for your help. Will be busy till tomorrow evening. Best regards -- 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 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. Wolfgang. ___ 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
On Sun, 2006-10-29 at 22:02 +0100, Niklaus Giger wrote: [...] > The trap 0 in /proc/xenomai/fault seems to count on each invocation of simple > 0: 51(Data or instruction access) This means that we do encounter minor or major faults which end up being gracefully handled. This could also happen upon request to expand the process stack (conversely, does raising the size of the process stack at init changes anything?). You may want to instrument arch/ppc/mm/fault.c:do_page_fault, in order to identify which faults are processed on behalf of the test thread. > 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. > > Best regards > -- Philippe. ___ 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 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 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. Best regards -- 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 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
While trying to make a small demo app for Xenomai's registry I stumbled
about the following bug of the vxWorks skin.
taskSuspend provokes (sometimes) a switch to the secondary mode, e.g.
the
output of the attached demo gives:
reg_demo &
~ $ Xenomai: Switching ConsumerTask to secondary mode after exception
#1025
This is the same issue that you raised back then, and that we did not
fix yet:
https://mail.gna.org/public/xenomai-core/2006-09/msg00177.html
#1025 looks like being an ISI exception due to some unmapped memory
being referred to. You mentioned CONFIG_XENO_OPT_DEBUG as possibly being
part of the problem/solution; could you check whether this error still
occurs when this option is disabled in the nucleus?
I recompiled the kernel with CONFIG_XENO_OPT_DEBUG disabled and the error
went away.
Actually I think the problem did not go away, as I did see that
in /proc/xenomai/faults the following error is incremented when I call the
attache simple program.
TRAP CPU0
0:5(Data or instruction access)
(Btw which exception is it attached on a PPC405 system?)
Here is the stack trace of the simplified example attached as seen by the BDI
with a hardware breakpoint at 0x300
#0 0x0300 in ?? ()
No symbol table info available.
#1 0x100b8c48 in ?? ()
No symbol table info available.
#2 0x100b8c48 in ?? ()
No symbol table info available.
Previous frame inner to this frame (corrupt stack?)
(gdb)
Setting a breakpoint at xnpod_fault_handler and a full backtrace gives me
(gdb) bt full
#0 xnpod_fault_handler (fltinfo=0xc1839e18)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/include/asm-generic/xenomai/system.h:200
thread = (xnthread_t *) 0xc0214f40
#1 0xc0048e90 in xnpod_trap_fault (fltinfo=0xc1839e18)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/xenomai/nucleus/pod.c:2907
No locals.
#2 0xc00438f4 in xnarch_trap_fault (event=3246628376, domid=1480937039,
data=0xc1839f50) at include2/asm/xenomai/bits/init.h:46
fltinfo = {exception = 0, regs = 0xc1839f50}
#3 0xc011ffb8 in exception_event (event=3221520296, ipd=0x58454e4f,
data=0xc1839f50)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/xenomai/hal.c:385
No locals.
#4 0xc003fecc in __ipipe_dispatch_event (event=0, data=0xc1839f50)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/ipipe/core.c:668
start_domain = (struct ipipe_domain *) 0xc0214f40
this_domain = (struct ipipe_domain *) 0xc0214f40
evhand = (ipipe_event_handler_t) 0xc0048e90
pos = (struct list_head *) 0xc0214f40
npos = (struct list_head *) 0xc01c6540
flags = 167984
propagate = 1
#5 0xc000b02c in do_page_fault (regs=0xc1839f50, address=266719224,
error_code=0)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/mm/fault.c:119
vma = (struct vm_area_struct *) 0xff86120
mm = (struct mm_struct *) 0xc0200260
info = {si_signo = 1, si_errno = -1071644672, si_code = -1071579136,
_sifields = {_pad = {0, -1048338784, -1048338608,
-1071554848, -1070595192, -1048338768, -1073423884, -1048338608, -1070595192, -1048338752, -1073422700,
0, 1, -1048338704,
-1073418440, -1071710208, 14, 1, -1071733764, -1071710208, -1071880896,
167984, 0, 16384, -1071880896, -1048338640, -1073479988,
0, 0}, _kill = {_pid = 0, _uid = 3246628512}, _timer = {_tid = 0,
_overrun = -1048338784,
_pad =
0xc1839e94 "Á\203\237PÀ!^àÀ0\003\210Á\203\236°À\004ÙôÁ\203\237PÀ0\003\210Á\203\236ÀÀ\004Þ\224",
_sigval = {
sival_int = -1048338608, sival_ptr = 0xc1839f50}, _sys_private
= -1071554848}, _rt = {_pid = 0, _uid = 3246628512, _sigval = {
sival_int = -1048338608, sival_ptr = 0xc1839f50}}, _sigchld = {_pid =
0, _uid = 3246628512, _status = -1048338608,
_utime = -1071554848, _stime = -1070595192}, _sigfault = {_addr = 0x0},
_sigpoll = {_band = 0, _fd = -1048338784}}}
code = 196609
is_write = 0
__func__ = "do_page_fault"
#6 0xc0003258 in handle_page_fault ()
No locals.
(gdb)
But I think it has something to do with my toolchain/compiler or my root file
system setup. I just found out, that compiling it with the same gcc 3.4
compiler for my PowerBook and linking it statically the error got away.
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.
Wolfgang.
/*
* Copyright (C)
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Am Samstag, 28. Oktober 2006 20:00 schrieb Philippe Gerum:
> On Sat, 2006-10-28 at 19:40 +0200, Niklaus Giger wrote:
> > > I recompiled the kernel with CONFIG_XENO_OPT_DEBUG disabled and the
> > > error went away.
> >
> > Actually I think the problem did not go away, as I did see that
> > in /proc/xenomai/faults the following error is incremented when I call
> > the attache simple program.
> > TRAP CPU0
> > 0:5(Data or instruction access)
> > (Btw which exception is it attached on a PPC405 system?)
>
> 0x400, e.g. page fault.
>
> > Here is the stack trace of the simplified example attached as seen by the
> > BDI with a hardware breakpoint at 0x300
> > #0 0x0300 in ?? ()
> > No symbol table info available.
> > #1 0x100b8c48 in ?? ()
> > No symbol table info available.
> > #2 0x100b8c48 in ?? ()
> > No symbol table info available.
> > Previous frame inner to this frame (corrupt stack?)
> > (gdb)
> >
> > Setting a breakpoint at xnpod_fault_handler and a full backtrace gives me
> > (gdb) bt full
> > #0 xnpod_fault_handler (fltinfo=0xc1839e18)
> > at
> > /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/include/asm-generic/xenomai/syst
> >em.h:200 thread = (xnthread_t *) 0xc0214f40
> > #1 0xc0048e90 in xnpod_trap_fault (fltinfo=0xc1839e18)
> > at
> > /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/xenomai/nucleus/pod.c:290
> >7 No locals.
> > #2 0xc00438f4 in xnarch_trap_fault (event=3246628376, domid=1480937039,
> > data=0xc1839f50) at include2/asm/xenomai/bits/init.h:46
> > fltinfo = {exception = 0, regs = 0xc1839f50}
> > #3 0xc011ffb8 in exception_event (event=3221520296, ipd=0x58454e4f,
> > data=0xc1839f50)
> > at
> > /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/xenomai/hal.c:385 No
> > locals.
> > #4 0xc003fecc in __ipipe_dispatch_event (event=0, data=0xc1839f50)
> > at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/ipipe/core.c:668
> > start_domain = (struct ipipe_domain *) 0xc0214f40
> > this_domain = (struct ipipe_domain *) 0xc0214f40
> > evhand = (ipipe_event_handler_t) 0xc0048e90
> > pos = (struct list_head *) 0xc0214f40
> > npos = (struct list_head *) 0xc01c6540
> > flags = 167984
> > propagate = 1
> > #5 0xc000b02c in do_page_fault (regs=0xc1839f50, address=266719224,
> > error_code=0)
> > at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/mm/fault.c:119
> > vma = (struct vm_area_struct *) 0xff86120
> > mm = (struct mm_struct *) 0xc0200260
> > info = {si_signo = 1, si_errno = -1071644672, si_code =
> > -1071579136, _sifields = {_pad = {0, -1048338784, -1048338608,
> > -1071554848, -1070595192, -1048338768, -1073423884, -1048338608,
> > -1070595192, -1048338752, -1073422700, 0, 1, -1048338704,
> > -1073418440, -1071710208, 14, 1, -1071733764, -1071710208,
> > -1071880896, 167984, 0, 16384, -1071880896, -1048338640, -1073479988,
> > 0, 0}, _kill = {_pid = 0, _uid = 3246628512}, _timer = {_tid = 0,
> > _overrun = -1048338784,
> > _pad =
> > 0xc1839e94
> > "Á\203\237PÀ!^àÀ0\003\210Á\203\236°À\004ÙôÁ\203\237PÀ0\003\210Á\203\236ÀÀ
> >\004Þ\224", _sigval = {
> > sival_int = -1048338608, sival_ptr = 0xc1839f50}, _sys_private
> > = -1071554848}, _rt = {_pid = 0, _uid = 3246628512, _sigval = {
> > sival_int = -1048338608, sival_ptr = 0xc1839f50}}, _sigchld =
> > {_pid = 0, _uid = 3246628512, _status = -1048338608,
> > _utime = -1071554848, _stime = -1070595192}, _sigfault = {_addr =
> > 0x0}, _sigpoll = {_band = 0, _fd = -1048338784}}}
> > code = 196609
> > is_write = 0
> > __func__ = "do_page_fault"
> > #6 0xc0003258 in handle_page_fault ()
> > No locals.
> > (gdb)
> >
> > But I think it has something to do with my toolchain/compiler or my root
> > file system setup. I just found out, that compiling it with the same gcc
> > 3.4 compiler for my PowerBook and linking it statically the error got
> > away.
>
> I tried to reproduce the issue on a lite5200 here, to no avail. I'm
> using gcc 4.0 from Denx's ELDK 4.0, but I've never had such problem when
> using gcc 3.3.3 from ELDK 3.1 either.
>
> I wonder if something fishy is not happening with the code gcc generates
> to emit syscalls in some place of the library support.
>
Could be. I have only a gdbserver running on the PPC405 system. I compiled
again without ld -static. Then I do the following:
> This GDB was configured as "powerpc-linux-gnu"...Using host libthread_db
> library "/lib/tls/libthread_db.so.1".
>
> (gdb) set solib-absolute-prefix /mnt/data.ng/hcu/rootfs
> (gdb) dir /mnt/data.ng/hcu/rootfs
> Source directories searched: /mnt/data.ng/hcu/rootfs:$cdir:$cwd
> (gdb) target remote 172.25.1.5:2345
> Remote debugging using 172.25.1.5:2345
> 0x3000fa18 in ?? ()
> (gdb) cont
> Continuing.
> [New thread 16384]
>
> Program received signal SIGILL, Illegal instruction.
> [Switching to thread 16384]
> 0x3000ca1c in _dl_name_match_p () from /mnt/data.ng/hcu/rootfs/lib
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
On Sat, 2006-10-28 at 19:40 +0200, Niklaus Giger wrote:
> Setting a breakpoint at xnpod_fault_handler and a full backtrace gives me
> (gdb) bt full
> #0 xnpod_fault_handler (fltinfo=0xc1839e18)
> at
> /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/include/asm-generic/xenomai/system.h:200
> thread = (xnthread_t *) 0xc0214f40
> #1 0xc0048e90 in xnpod_trap_fault (fltinfo=0xc1839e18)
> at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/xenomai/nucleus/pod.c:2907
> No locals.
> #2 0xc00438f4 in xnarch_trap_fault (event=3246628376, domid=1480937039,
> data=0xc1839f50) at include2/asm/xenomai/bits/init.h:46
> fltinfo = {exception = 0, regs = 0xc1839f50}
> #3 0xc011ffb8 in exception_event (event=3221520296, ipd=0x58454e4f,
> data=0xc1839f50)
> at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/xenomai/hal.c:385
> No locals.
> #4 0xc003fecc in __ipipe_dispatch_event (event=0, data=0xc1839f50)
> at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/ipipe/core.c:668
> start_domain = (struct ipipe_domain *) 0xc0214f40
> this_domain = (struct ipipe_domain *) 0xc0214f40
> evhand = (ipipe_event_handler_t) 0xc0048e90
> pos = (struct list_head *) 0xc0214f40
> npos = (struct list_head *) 0xc01c6540
> flags = 167984
> propagate = 1
> #5 0xc000b02c in do_page_fault (regs=0xc1839f50, address=266719224,
> error_code=0)
> at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/mm/fault.c:119
> vma = (struct vm_area_struct *) 0xff86120
> mm = (struct mm_struct *) 0xc0200260
> info = {si_signo = 1, si_errno = -1071644672, si_code = -1071579136,
> _sifields = {_pad = {0, -1048338784, -1048338608,
> -1071554848, -1070595192, -1048338768, -1073423884, -1048338608,
> -1070595192, -1048338752, -1073422700,
> 0, 1, -1048338704,
> -1073418440, -1071710208, 14, 1, -1071733764, -1071710208, -1071880896,
> 167984, 0, 16384, -1071880896, -1048338640, -1073479988,
> 0, 0}, _kill = {_pid = 0, _uid = 3246628512}, _timer = {_tid = 0,
> _overrun = -1048338784,
> _pad =
> 0xc1839e94
> "Á\203\237PÀ!^àÀ0\003\210Á\203\236°À\004ÙôÁ\203\237PÀ0\003\210Á\203\236ÀÀ\004Þ\224",
>
> _sigval = {
> sival_int = -1048338608, sival_ptr = 0xc1839f50}, _sys_private
> = -1071554848}, _rt = {_pid = 0, _uid = 3246628512, _sigval = {
> sival_int = -1048338608, sival_ptr = 0xc1839f50}}, _sigchld = {_pid =
> 0, _uid = 3246628512, _status = -1048338608,
> _utime = -1071554848, _stime = -1070595192}, _sigfault = {_addr = 0x0},
> _sigpoll = {_band = 0, _fd = -1048338784}}}
> code = 196609
> is_write = 0
> __func__ = "do_page_fault"
> #6 0xc0003258 in handle_page_fault ()
> No locals.
> (gdb)
This looks like a sane kernel call frame for handling an invalid memory
dereference from user-space. Running the faulting application over GDB
would probably give us more information.
>
--
Philippe.
___
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
On Sat, 2006-10-28 at 19:40 +0200, Niklaus Giger wrote:
> > I recompiled the kernel with CONFIG_XENO_OPT_DEBUG disabled and the error
> > went away.
> Actually I think the problem did not go away, as I did see that
> in /proc/xenomai/faults the following error is incremented when I call the
> attache simple program.
> TRAP CPU0
> 0:5(Data or instruction access)
> (Btw which exception is it attached on a PPC405 system?)
>
0x400, e.g. page fault.
> Here is the stack trace of the simplified example attached as seen by the BDI
> with a hardware breakpoint at 0x300
> #0 0x0300 in ?? ()
> No symbol table info available.
> #1 0x100b8c48 in ?? ()
> No symbol table info available.
> #2 0x100b8c48 in ?? ()
> No symbol table info available.
> Previous frame inner to this frame (corrupt stack?)
> (gdb)
>
> Setting a breakpoint at xnpod_fault_handler and a full backtrace gives me
> (gdb) bt full
> #0 xnpod_fault_handler (fltinfo=0xc1839e18)
> at
> /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/include/asm-generic/xenomai/system.h:200
> thread = (xnthread_t *) 0xc0214f40
> #1 0xc0048e90 in xnpod_trap_fault (fltinfo=0xc1839e18)
> at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/xenomai/nucleus/pod.c:2907
> No locals.
> #2 0xc00438f4 in xnarch_trap_fault (event=3246628376, domid=1480937039,
> data=0xc1839f50) at include2/asm/xenomai/bits/init.h:46
> fltinfo = {exception = 0, regs = 0xc1839f50}
> #3 0xc011ffb8 in exception_event (event=3221520296, ipd=0x58454e4f,
> data=0xc1839f50)
> at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/xenomai/hal.c:385
> No locals.
> #4 0xc003fecc in __ipipe_dispatch_event (event=0, data=0xc1839f50)
> at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/ipipe/core.c:668
> start_domain = (struct ipipe_domain *) 0xc0214f40
> this_domain = (struct ipipe_domain *) 0xc0214f40
> evhand = (ipipe_event_handler_t) 0xc0048e90
> pos = (struct list_head *) 0xc0214f40
> npos = (struct list_head *) 0xc01c6540
> flags = 167984
> propagate = 1
> #5 0xc000b02c in do_page_fault (regs=0xc1839f50, address=266719224,
> error_code=0)
> at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/mm/fault.c:119
> vma = (struct vm_area_struct *) 0xff86120
> mm = (struct mm_struct *) 0xc0200260
> info = {si_signo = 1, si_errno = -1071644672, si_code = -1071579136,
> _sifields = {_pad = {0, -1048338784, -1048338608,
> -1071554848, -1070595192, -1048338768, -1073423884, -1048338608,
> -1070595192, -1048338752, -1073422700,
> 0, 1, -1048338704,
> -1073418440, -1071710208, 14, 1, -1071733764, -1071710208, -1071880896,
> 167984, 0, 16384, -1071880896, -1048338640, -1073479988,
> 0, 0}, _kill = {_pid = 0, _uid = 3246628512}, _timer = {_tid = 0,
> _overrun = -1048338784,
> _pad =
> 0xc1839e94
> "Á\203\237PÀ!^àÀ0\003\210Á\203\236°À\004ÙôÁ\203\237PÀ0\003\210Á\203\236ÀÀ\004Þ\224",
>
> _sigval = {
> sival_int = -1048338608, sival_ptr = 0xc1839f50}, _sys_private
> = -1071554848}, _rt = {_pid = 0, _uid = 3246628512, _sigval = {
> sival_int = -1048338608, sival_ptr = 0xc1839f50}}, _sigchld = {_pid =
> 0, _uid = 3246628512, _status = -1048338608,
> _utime = -1071554848, _stime = -1070595192}, _sigfault = {_addr = 0x0},
> _sigpoll = {_band = 0, _fd = -1048338784}}}
> code = 196609
> is_write = 0
> __func__ = "do_page_fault"
> #6 0xc0003258 in handle_page_fault ()
> No locals.
> (gdb)
>
> But I think it has something to do with my toolchain/compiler or my root file
> system setup. I just found out, that compiling it with the same gcc 3.4
> compiler for my PowerBook and linking it statically the error got away.
>
I tried to reproduce the issue on a lite5200 here, to no avail. I'm
using gcc 4.0 from Denx's ELDK 4.0, but I've never had such problem when
using gcc 3.3.3 from ELDK 3.1 either.
I wonder if something fishy is not happening with the code gcc generates
to emit syscalls in some place of the library support.
> I think I really have to reactivate my old Walnut board to have common
> platform to test with Wolfgang Grandegger.
>
> Best regards
>
--
Philippe.
___
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 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
> > >
> > > While trying to make a small demo app for Xenomai's registry I stumbled
> > > about the following bug of the vxWorks skin.
> > >
> > > taskSuspend provokes (sometimes) a switch to the secondary mode, e.g.
> > > the
> > >
> > > output of the attached demo gives:
> > > > reg_demo &
> > > > ~ $ Xenomai: Switching ConsumerTask to secondary mode after exception
> > > > #1025
> >
> > This is the same issue that you raised back then, and that we did not
> > fix yet:
> > https://mail.gna.org/public/xenomai-core/2006-09/msg00177.html
> >
> > #1025 looks like being an ISI exception due to some unmapped memory
> > being referred to. You mentioned CONFIG_XENO_OPT_DEBUG as possibly being
> > part of the problem/solution; could you check whether this error still
> > occurs when this option is disabled in the nucleus?
>
> I recompiled the kernel with CONFIG_XENO_OPT_DEBUG disabled and the error
> went away.
Actually I think the problem did not go away, as I did see that
in /proc/xenomai/faults the following error is incremented when I call the
attache simple program.
TRAP CPU0
0:5(Data or instruction access)
(Btw which exception is it attached on a PPC405 system?)
Here is the stack trace of the simplified example attached as seen by the BDI
with a hardware breakpoint at 0x300
#0 0x0300 in ?? ()
No symbol table info available.
#1 0x100b8c48 in ?? ()
No symbol table info available.
#2 0x100b8c48 in ?? ()
No symbol table info available.
Previous frame inner to this frame (corrupt stack?)
(gdb)
Setting a breakpoint at xnpod_fault_handler and a full backtrace gives me
(gdb) bt full
#0 xnpod_fault_handler (fltinfo=0xc1839e18)
at
/mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/include/asm-generic/xenomai/system.h:200
thread = (xnthread_t *) 0xc0214f40
#1 0xc0048e90 in xnpod_trap_fault (fltinfo=0xc1839e18)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/xenomai/nucleus/pod.c:2907
No locals.
#2 0xc00438f4 in xnarch_trap_fault (event=3246628376, domid=1480937039,
data=0xc1839f50) at include2/asm/xenomai/bits/init.h:46
fltinfo = {exception = 0, regs = 0xc1839f50}
#3 0xc011ffb8 in exception_event (event=3221520296, ipd=0x58454e4f,
data=0xc1839f50)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/xenomai/hal.c:385
No locals.
#4 0xc003fecc in __ipipe_dispatch_event (event=0, data=0xc1839f50)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/ipipe/core.c:668
start_domain = (struct ipipe_domain *) 0xc0214f40
this_domain = (struct ipipe_domain *) 0xc0214f40
evhand = (ipipe_event_handler_t) 0xc0048e90
pos = (struct list_head *) 0xc0214f40
npos = (struct list_head *) 0xc01c6540
flags = 167984
propagate = 1
#5 0xc000b02c in do_page_fault (regs=0xc1839f50, address=266719224,
error_code=0)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/mm/fault.c:119
vma = (struct vm_area_struct *) 0xff86120
mm = (struct mm_struct *) 0xc0200260
info = {si_signo = 1, si_errno = -1071644672, si_code = -1071579136,
_sifields = {_pad = {0, -1048338784, -1048338608,
-1071554848, -1070595192, -1048338768, -1073423884, -1048338608,
-1070595192, -1048338752, -1073422700,
0, 1, -1048338704,
-1073418440, -1071710208, 14, 1, -1071733764, -1071710208, -1071880896,
167984, 0, 16384, -1071880896, -1048338640, -1073479988,
0, 0}, _kill = {_pid = 0, _uid = 3246628512}, _timer = {_tid = 0,
_overrun = -1048338784,
_pad =
0xc1839e94
"Á\203\237PÀ!^àÀ0\003\210Á\203\236°À\004ÙôÁ\203\237PÀ0\003\210Á\203\236ÀÀ\004Þ\224",
_sigval = {
sival_int = -1048338608, sival_ptr = 0xc1839f50}, _sys_private
= -1071554848}, _rt = {_pid = 0, _uid = 3246628512, _sigval = {
sival_int = -1048338608, sival_ptr = 0xc1839f50}}, _sigchld = {_pid =
0, _uid = 3246628512, _status = -1048338608,
_utime = -1071554848, _stime = -1070595192}, _sigfault = {_addr = 0x0},
_sigpoll = {_band = 0, _fd = -1048338784}}}
code = 196609
is_write = 0
__func__ = "do_page_fault"
#6 0xc0003258 in handle_page_fault ()
No locals.
(gdb)
But I think it has something to do with my toolchain/compiler or my root file
system setup. I just found out, that compiling it with the same gcc 3.4
compiler for my PowerBook and linking it statically the error got away.
I think I really have to reactivate my old Walnut board to have common
platform to test with Wolfgang Grandegger.
Best regards
--
Niklaus Giger
/*
* Copyright (C) 2006 Niklaus Giger <[EMAIL PROTECTED]>.
*
* VxWorks is a registered trademark of Wind River Systems, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
On Sat, 2006-10-28 at 14:54 +0200, Niklaus Giger wrote: > Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum: > > On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote: > > > Hi > > > > > > While trying to make a small demo app for Xenomai's registry I stumbled > > > about the following bug of the vxWorks skin. > > > > > > taskSuspend provokes (sometimes) a switch to the secondary mode, e.g. the > > > > > > output of the attached demo gives: > > > > reg_demo & > > > > ~ $ Xenomai: Switching ConsumerTask to secondary mode after exception > > > > #1025 > > > > This is the same issue that you raised back then, and that we did not > > fix yet: > > https://mail.gna.org/public/xenomai-core/2006-09/msg00177.html > > > > #1025 looks like being an ISI exception due to some unmapped memory > > being referred to. You mentioned CONFIG_XENO_OPT_DEBUG as possibly being > > part of the problem/solution; could you check whether this error still > > occurs when this option is disabled in the nucleus? > I recompiled the kernel with CONFIG_XENO_OPT_DEBUG disabled and the error > went > away.a Does disabling CONFIG_XENO_OPT_DEBUG_QUEUES while keeping CONFIG_XENO_OPT_DEBUG enabled change anything? -- Philippe. ___ 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 Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum: > On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote: > > Hi > > > > While trying to make a small demo app for Xenomai's registry I stumbled > > about the following bug of the vxWorks skin. > > > > taskSuspend provokes (sometimes) a switch to the secondary mode, e.g. the > > > > output of the attached demo gives: > > > reg_demo & > > > ~ $ Xenomai: Switching ConsumerTask to secondary mode after exception > > > #1025 > > This is the same issue that you raised back then, and that we did not > fix yet: > https://mail.gna.org/public/xenomai-core/2006-09/msg00177.html > > #1025 looks like being an ISI exception due to some unmapped memory > being referred to. You mentioned CONFIG_XENO_OPT_DEBUG as possibly being > part of the problem/solution; could you check whether this error still > occurs when this option is disabled in the nucleus? I recompiled the kernel with CONFIG_XENO_OPT_DEBUG disabled and the error went away. -- 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
On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote: > Hi > > While trying to make a small demo app for Xenomai's registry I stumbled about > the following bug of the vxWorks skin. > > taskSuspend provokes (sometimes) a switch to the secondary mode, e.g. the > output of the attached demo gives: > > reg_demo & > > ~ $ Xenomai: Switching ConsumerTask to secondary mode after exception #1025 This is the same issue that you raised back then, and that we did not fix yet: https://mail.gna.org/public/xenomai-core/2006-09/msg00177.html #1025 looks like being an ISI exception due to some unmapped memory being referred to. You mentioned CONFIG_XENO_OPT_DEBUG as possibly being part of the problem/solution; could you check whether this error still occurs when this option is disabled in the nucleus? -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Bug in taskSuspend for user mode vxworks
Hi
While trying to make a small demo app for Xenomai's registry I stumbled about
the following bug of the vxWorks skin.
taskSuspend provokes (sometimes) a switch to the secondary mode, e.g. the
output of the attached demo gives:
> reg_demo &
> ~ $ Xenomai: Switching ConsumerTask to secondary mode after exception #1025
> from user-space at 0xfe5cff8 (pid 27) consumer_task: 13129 Started
> producer_task: 13258 Started xx
> lockForward: 13259 Started
> producer_task: 13260 msg sent 0
> lockForward: 13260 got both mutexes
> lockBackward: 13260 Started
> producer_task: 13261 msg sent 0
> producer_task: 13261 done
> Now playing first msg...
> consumer_task: 13262 Suspending myself. After receiving sz 16
>
> This is a small demo for the debugging option CONFIG_XENO_EXPORT_REGISTRY.
> If you compile the xenomai kernel with CONFIG_XENO_EXPORT_REGISTRY=y
> in your kernel .config you will find files under /proc/xenomai/registry.
> tasks/*: gives information about running vxworks tasks
> semaphores/*: gives information about the vxworks semaphores
> msgqs/*: gives information about the vxworks message queues
>
> Some vxWorks tasks should be blocked. Now enter:
> ls -R /proc/xenomai/registry/vxworks/* && cat
> /proc/xenomai/registry/vxworks/*/* lockForward: 13271 will give both
> mutexes
> lockForward: 13271 Done
Running the same program under the simulator gave me the expected output
I had not yet time to track down the error, but any help would be appreciated.
Thanks in advance
Best regards
--
Niklaus Giger
/*
* Copyright (C) 2006 Niklaus Giger <[EMAIL PROTECTED]>.
*
* VxWorks is a registered trademark of Wind River Systems, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
#include
#define ROOT_TASK_PRI100
#define ROOT_STACK_SIZE 16*1024
#define CONSUMER_TASK_PRI115
#define CONSUMER_STACK_SIZE 24*1024
#define PRODUCER_TASK_PRI110
#define PRODUCER_STACK_SIZE 24*1024
#define CONSUMER_WAIT 150
#define PRODUCER_TRIG 40
int root_thread_init(void);
void root_thread_exit(void);
#if !defined(__KERNEL__) && !defined(__XENO_SIM__)
#include
#include
#include
#include
#define MODULE_LICENSE(x)
#define xnprintf printf
int main (int argc, char *argv[])
{
int tid;
mlockall(MCL_CURRENT|MCL_FUTURE);
atexit(&root_thread_exit);
tid = taskSpawn("RootTask",
ROOT_TASK_PRI,
0,
ROOT_STACK_SIZE,
(FUNCPTR)&root_thread_init,
0,0,0,0,0,0,0,0,0,0);
if (tid)
pause();
return 1;
}
#endif /* Native, user-space execution */
MODULE_LICENSE("GPL");
static int producer_tid,
consumer_tid,
message_qid,
emptySema,
fullSema,
countingSema,
mutexForward,
mutexBackward;
void lockForward (int a0, int a1, int a2, int a3, int a4,
int a5, int a6, int a7, int a8, int a9)
{
xnprintf("%s: %d Started\n",__FUNCTION__, tickGet());
semTake(mutexForward, WAIT_FOREVER);
semTake(mutexBackward, WAIT_FOREVER);
xnprintf("%s: %d got both mutexes\n",__FUNCTION__, tickGet());
taskDelay(10);
xnprintf("%s: %d will give both mutexes\n",__FUNCTION__, tickGet());
semGive(mutexBackward);
semGive(mutexForward);
xnprintf("%s: %d Done\n",__FUNCTION__, tickGet());
taskExit(0);
}
void lockBackward (int a0, int a1, int a2, int a3, int a4,
int a5, int a6, int a7, int a8, int a9)
{
xnprintf("%s: %d Started\n",__FUNCTION__, tickGet());
semTake(mutexBackward, WAIT_FOREVER);
semTake(mutexForward, WAIT_FOREVER);
xnprintf("%s: %d got both mutexes\n",__FUNCTION__, tickGet());
taskDelay(10);
xnprintf("%s: %d will give both mutexes\n",__FUNCTION__, tickGet());
semGive(mutexForward);
semGive(mutexBackward);
xnprintf("%s: %d Done\n",__FUNCTION__, tickGet());
taskExit(0);
}
#define MSG_SIZE 16
void consumer_task (int a0, int a1, int a2, int a3, int a4,
int a5, int a6, int a7, int a8, int a9)
{
char msg[MSG_SIZE];
int sz;
xnprintf("%s: %d Started\n",__FUNCTION__, tickGet());
if ((sz = msgQReceive(message_qid,(char *)&msg,sizeof(msg), 100)) != ERROR)
xnprintf("Now playing %s...\n",msg);
xnprintf("%s: %d Suspending myself. After receiving sz %d\n",__FUNCTION__, tickGet(), sz);
taskSuspend(taskIdSelf());
xnprintf
