Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Am Mittwoch, 27. September 2006 20:19 schrieb Wolfgang Grandegger: .. I'm now a bit puzzled why a FP exception occurs. What happens if you disable MATH_EMULATION in your kernel (that's what I normally have). It will try the latency test on my Walnut-Board with CONFIG_XENO_OPT_DEBUG asap. I'm unable to reproduce the problem of our Sycamore board with Linux 2.6.14: Can I you send me (maybe offline) your .config. I will also rebuild my rootfs from scratch. At work I have also a walnut board where I could run the tests. CPU: AMCC PowerPC 405GPr Rev. B at 333.333 MHz (PLB=133, OPB=66, EBC=66 MHz) Internal PCI arbiter enabled, PCI async ext clock used 16 kB I-Cache 16 kB D-Cache Board: Sycamore - AMCC PPC405GPr Evaluation Board Thanks for trying to reproduce the problem. -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Niklaus Giger wrote: Am Mittwoch, 27. September 2006 20:19 schrieb Wolfgang Grandegger: .. I'm now a bit puzzled why a FP exception occurs. What happens if you disable MATH_EMULATION in your kernel (that's what I normally have). It will try the latency test on my Walnut-Board with CONFIG_XENO_OPT_DEBUG asap. I'm unable to reproduce the problem of our Sycamore board with Linux 2.6.14: Can I you send me (maybe offline) your .config. I will also rebuild my rootfs from scratch. At work I have also a walnut board where I could run the tests. See attachment. And I tested with a Sycamore Evaluation Board, which uses the same processor as you have. Likely, it has nothing to do with the board. Does your kernel boot with MATH_EMULATION disabled? Can you then run user-space applications using FP. CPU: AMCC PowerPC 405GPr Rev. B at 333.333 MHz (PLB=133, OPB=66, EBC=66 MHz) Internal PCI arbiter enabled, PCI async ext clock used 16 kB I-Cache 16 kB D-Cache Board: Sycamore - AMCC PPC405GPr Evaluation Board Thanks for trying to reproduce the problem. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.14 # Wed Sep 27 14:21:27 2006 # CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_PPC=y CONFIG_PPC32=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set # CONFIG_HOTPLUG is not set CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set CONFIG_INITRAMFS_SOURCE= CONFIG_EMBEDDED=y # CONFIG_KALLSYMS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y # CONFIG_EPOLL is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Real-time sub-system # CONFIG_XENOMAI=y CONFIG_XENO_OPT_NUCLEUS=y CONFIG_XENO_OPT_PERVASIVE=y # CONFIG_XENO_OPT_ISHIELD is not set # CONFIG_XENO_OPT_RPIDISABLE is not set CONFIG_XENO_OPT_SECURITY_ACCESS=y CONFIG_XENO_OPT_PIPELINE_HEAD=y CONFIG_XENO_OPT_PIPE=y CONFIG_XENO_OPT_PIPE_NRDEV=32 CONFIG_XENO_OPT_REGISTRY=y CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512 CONFIG_XENO_OPT_SYS_HEAPSZ=128 CONFIG_XENO_OPT_STATS=y CONFIG_XENO_OPT_DEBUG=y # CONFIG_XENO_OPT_DEBUG_QUEUES is not set CONFIG_XENO_OPT_DEBUG_BHEAP=y # CONFIG_XENO_OPT_WATCHDOG is not set # # Timing # # CONFIG_XENO_OPT_TIMING_PERIODIC is not set CONFIG_XENO_OPT_TIMING_PERIOD=0 CONFIG_XENO_OPT_TIMING_TIMERLAT=0 CONFIG_XENO_OPT_TIMING_SCHEDLAT=0 # # Scalability # # CONFIG_XENO_OPT_SCALABLE_SCHED is not set CONFIG_XENO_OPT_TIMER_LIST=y # CONFIG_XENO_OPT_TIMER_HEAP is not set # CONFIG_XENO_OPT_TIMER_WHEEL is not set # # Shared interrupts # # CONFIG_XENO_OPT_SHIRQ_LEVEL is not set # CONFIG_XENO_OPT_SHIRQ_EDGE is not set # # Machine # # # Interfaces # CONFIG_XENO_SKIN_NATIVE=y CONFIG_XENO_OPT_NATIVE_PIPE=y CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096 CONFIG_XENO_OPT_NATIVE_REGISTRY=y CONFIG_XENO_OPT_NATIVE_SEM=y CONFIG_XENO_OPT_NATIVE_EVENT=y CONFIG_XENO_OPT_NATIVE_MUTEX=y CONFIG_XENO_OPT_NATIVE_COND=y CONFIG_XENO_OPT_NATIVE_QUEUE=y CONFIG_XENO_OPT_NATIVE_HEAP=y CONFIG_XENO_OPT_NATIVE_ALARM=y CONFIG_XENO_OPT_NATIVE_MPS=y # CONFIG_XENO_OPT_NATIVE_INTR is not set CONFIG_XENO_SKIN_POSIX=y # CONFIG_XENO_OPT_POSIX_SHM is not set # CONFIG_XENO_OPT_POSIX_INTR is not set # CONFIG_XENO_SKIN_PSOS is not set # CONFIG_XENO_SKIN_UITRON is not set # CONFIG_XENO_SKIN_VRTX is not set # CONFIG_XENO_SKIN_VXWORKS is not set # CONFIG_XENO_SKIN_RTAI is not set CONFIG_XENO_SKIN_RTDM=y CONFIG_XENO_OPT_RTDM_FILDES=128 # CONFIG_XENO_OPT_DEBUG_RTDM is not set # # Drivers # # # Serial drivers # # CONFIG_XENO_DRIVERS_16550A is not set # # Testing drivers # CONFIG_XENO_DRIVERS_TIMERBENCH=y # CONFIG_XENO_DRIVERS_IRQBENCH is not set CONFIG_XENO_DRIVERS_SWITCHTEST=y # # CAN drivers # # CONFIG_XENO_DRIVERS_RTCAN is not set # # Processor # # CONFIG_6xx is not set CONFIG_40x=y # CONFIG_44x is not set # CONFIG_POWER3 is not set # CONFIG_POWER4 is not set # CONFIG_8xx is not set # CONFIG_E200 is not set # CONFIG_E500 is not set # CONFIG_MATH_EMULATION is not set # CONFIG_KEXEC is not set # CONFIG_CPU_FREQ is not set CONFIG_4xx=y # CONFIG_WANT_EARLY_SERIAL is not set # # IBM 4xx options # # CONFIG_BUBINGA is not set # CONFIG_CPCI405 is not set # CONFIG_EP405 is not set #
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Niklaus Giger wrote: Am Dienstag, 26. September 2006 22:23 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Dienstag, 26. September 2006 18:28 schrieb Wolfgang Grandegger: Philippe Gerum wrote: On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote: OK, but in general, soft-float emulation should be used on systems without FPU and this is even more important for real-time. This is a tool chain issue. Niklaus, what tool chain are you using? In my .config I have MATH_EMULATION=y You seem to need that because your compiler generates code with hard FP instructions. You could check this with: $ ppc-linux-objdump -d prog|egrep :\s*[e-f] This does not return any match on my system. Oops, then your compiler seems _not_ to create hard FP instruction, otherwise you would get: ppc_82xx-objdump -d latency|egrep :\s*[e-f] latency: file format elf32-powerpc 100036ac: fc 21 f8 28 fsubf1,f1,f31 100036b4: fc 42 f8 28 fsubf2,f2,f31 100036c4: fc 63 f8 28 fsubf3,f3,f31 100036cc: fc 21 f0 24 fdivf1,f1,f30 100036dc: fc 84 f8 28 fsubf4,f4,f31 ... But looking at the disassembly of the latency program I have code like: 100081bc _restfpr_28_x: 100081bc: cb 8b ff e0 lfd f28,-32(r11) or 1000798c __floatsidf: 1000798c: 7c 08 02 a6 mflrr0 10007990: 2f 83 00 00 cmpwi cr7,r3,0 10007994: 94 21 ff c0 stwur1,-64(r1) 10007998: 90 01 00 44 stw r0,68(r1) 1000799c: 54 60 0f fe rlwinm r0,r3,1,31,31 100079a0: 90 01 00 14 stw r0,20(r1) 100079a4: 40 9e 00 24 bne-cr7,100079c8 __floatsidf+0x3c That's from soft float emulation. The toolchain is gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu built using Dan Kegel crosstool (Version 0.42 if I remember exactly). Shall I switch to another one? Maybe (likely) there is nothing wrong with your tool chain. The ELDK from DENX uses FP soft-emulation for 4xx (http://www.denx.de). Choose v3.1.1 for Linux 2.4 and v4 for Linux 2.6. I am breathing only PowerPC code on my Mac PowerBook (running Debian) and never managed to installed ELDK on it. (And even Detlev as a Debian developer couldn't recommend a simple way.) I remember Detlev's pain and frustration. But I assume that I specifying GLIBC_EXTRA_CONFIG=--without-fp in the powerpc-405.dat should be enough to make Dan Kegels crosstool emit Soft-FPU emulation. See above. I will try to run the tests at work where I have installed ELDK 4.0, but not yet a fully working environment. Therefore it may take some time to report a result back. I'm now a bit puzzled why a FP exception occurs. What happens if you disable MATH_EMULATION in your kernel (that's what I normally have). It will try the latency test on my Walnut-Board with CONFIG_XENO_OPT_DEBUG asap. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Wolfgang Grandegger wrote: Niklaus Giger wrote: Am Dienstag, 26. September 2006 22:23 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Dienstag, 26. September 2006 18:28 schrieb Wolfgang Grandegger: Philippe Gerum wrote: On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote: OK, but in general, soft-float emulation should be used on systems without FPU and this is even more important for real-time. This is a tool chain issue. Niklaus, what tool chain are you using? In my .config I have MATH_EMULATION=y You seem to need that because your compiler generates code with hard FP instructions. You could check this with: $ ppc-linux-objdump -d prog|egrep :\s*[e-f] This does not return any match on my system. Oops, then your compiler seems _not_ to create hard FP instruction, otherwise you would get: ppc_82xx-objdump -d latency|egrep :\s*[e-f] latency: file format elf32-powerpc 100036ac: fc 21 f8 28 fsubf1,f1,f31 100036b4: fc 42 f8 28 fsubf2,f2,f31 100036c4: fc 63 f8 28 fsubf3,f3,f31 100036cc: fc 21 f0 24 fdivf1,f1,f30 100036dc: fc 84 f8 28 fsubf4,f4,f31 ... But looking at the disassembly of the latency program I have code like: 100081bc _restfpr_28_x: 100081bc: cb 8b ff e0 lfd f28,-32(r11) or 1000798c __floatsidf: 1000798c: 7c 08 02 a6 mflrr0 10007990: 2f 83 00 00 cmpwi cr7,r3,0 10007994: 94 21 ff c0 stwur1,-64(r1) 10007998: 90 01 00 44 stw r0,68(r1) 1000799c: 54 60 0f fe rlwinm r0,r3,1,31,31 100079a0: 90 01 00 14 stw r0,20(r1) 100079a4: 40 9e 00 24 bne-cr7,100079c8 __floatsidf+0x3c That's from soft float emulation. The toolchain is gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu built using Dan Kegel crosstool (Version 0.42 if I remember exactly). Shall I switch to another one? Maybe (likely) there is nothing wrong with your tool chain. The ELDK from DENX uses FP soft-emulation for 4xx (http://www.denx.de). Choose v3.1.1 for Linux 2.4 and v4 for Linux 2.6. I am breathing only PowerPC code on my Mac PowerBook (running Debian) and never managed to installed ELDK on it. (And even Detlev as a Debian developer couldn't recommend a simple way.) I remember Detlev's pain and frustration. But I assume that I specifying GLIBC_EXTRA_CONFIG=--without-fp in the powerpc-405.dat should be enough to make Dan Kegels crosstool emit Soft-FPU emulation. See above. I will try to run the tests at work where I have installed ELDK 4.0, but not yet a fully working environment. Therefore it may take some time to report a result back. I'm now a bit puzzled why a FP exception occurs. What happens if you disable MATH_EMULATION in your kernel (that's what I normally have). It will try the latency test on my Walnut-Board with CONFIG_XENO_OPT_DEBUG asap. I'm unable to reproduce the problem of our Sycamore board with Linux 2.6.14: CPU: AMCC PowerPC 405GPr Rev. B at 333.333 MHz (PLB=133, OPB=66, EBC=66 MHz) Internal PCI arbiter enabled, PCI async ext clock used 16 kB I-Cache 16 kB D-Cache Board: Sycamore - AMCC PPC405GPr Evaluation Board Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Niklaus Giger wrote: Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum: On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote: Niklaus Giger wrote: .. Ok, we can go for the lazy fix here, since this code is poised to disappear anyway. I've merged a variant of the above we already use for the ARM port, which scales down the period to microseconds instead of losing precision on the count of timebase ticks per jiffy. - ticks = ns * tb_ticks_per_jiffy / (10 / HZ); + ticks = (ns / 1000) * tb_ticks_per_jiffy / (100 / HZ); Thanks for finding this solution. I tried to understand mulhwu and mulhwu_scale_factor but couldn't figure out a correct solution in a short time. I took me also some time to understand the meaning. mulhwu(a,b) returns the high 32 bits (32..63) of a*b. A possible quick fix could be: if (mulhwu(ns, tb_ticks_per_jiffy) 0) ticks = (ns / 1000) * tb_ticks_per_jiffy / (100 / HZ); else ticks = ns * tb_ticks_per_jiffy / (10 / HZ); But Philippe already applied a reasonable fix. The buildbot cannot presently power on and off my PPC405 target board, as the my power outlet switching device is broken and has been sent back for a remplacement. I did however run some tests manually and have the following questions about the output: Why do I get negative values for latenciy values? Is the output of lines like Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) harmless or the result of a activated CONFIG_XENO_OPT_DEBUG.. option? Mon Sep 25 20:20:33 UTC 2006 running: ./run -- -T 5 -t2 # latency * * * Type ^C to stop this application. * Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) == Sampling period: 100 us == Test mode: in-kernel timer handler == All results in microseconds warming up... RTT| 00:00:01 (in-kernel timer handler, 100 us period, priority 99) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD| -5.108| -4.754| -0.905| 0| -5.108| -0.905 RTD| -4.963| -4.871| 1.155| 0| -5.108| 1.155 Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0xfda9638 (pid 3240) RTD| -4.963| -4.758| 16.020| 0| -5.108| 16.020 RTD| -6.313| -4.861| 10.980| 0| -6.313| 16.020 Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0xfe7c1c4 (pid 3240) ---|||||- RTS| -6.313| -4.811| 16.020| 0|00:00:05/00:00:05 Xenomai: stopping RTDM services. Best regards ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
On Mon, 2006-09-25 at 23:15 +0200, Niklaus Giger wrote: Am Montag, 25. September 2006 22:59 schrieb Philippe Gerum: On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote: Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum: On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote: Niklaus Giger wrote: .. Is the output of lines like Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) harmless or the result of a activated CONFIG_XENO_OPT_DEBUG.. option? Oops. It's bad news. A memory access error occured while running the test. Which Xenomai/Adeos combo are you currently running on the 4xx? adeos-ipipe-2.6.14-ppc-1.4-00.patch Shall I use my BDI (tomorrow evening) to get a stack trace of it? Or something else you would like to see? It would be great if you could first run the very same Xenomai config over Adeos 1.3-07 instead of 1.4-00, just to see if the issue is still there on the 4xx. After that, a BDI trace would be nice to have when time permits. Best regards -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote:
Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum:
On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote:
Niklaus Giger wrote:
..
Is the output of lines like Xenomai: Switching display-3238 to secondary
mode after exception #1025 from user-space at 0x100033c4 (pid 3240)
harmless or the result of a activated CONFIG_XENO_OPT_DEBUG.. option?
A known hw issue seems to exist with the 405GP (revD), which causes the
ESR to be incorrectly set upon FPU emulation trap, which would in turn
cause the spurious exception to be relayed to the nucleus by Adeos. The
patch below is _not_ the final fix, but rather a way to check if this
message is indeed related to the FPU emulation on your board. Does it
silence the exception without breaking the box?
--- arch/ppc/kernel/traps.c~2006-09-25 17:10:48.0 +0200
+++ arch/ppc/kernel/traps.c 2006-09-26 16:14:30.0 +0200
@@ -638,9 +638,6 @@
unsigned int reason = get_reason(regs);
extern int do_mathemu(struct pt_regs *regs);
- if (ipipe_trap_notify(IPIPE_TRAP_PCE,regs))
- return;
-
#ifdef CONFIG_MATH_EMULATION
/* (reason REASON_ILLEGAL) would be the obvious thing here,
* but there seems to be a hardware bug on the 405GP (RevD)
@@ -655,6 +652,9 @@
}
#endif /* CONFIG_MATH_EMULATION */
+ if (ipipe_trap_notify(IPIPE_TRAP_PCE,regs))
+ return;
+
if (reason REASON_FP) {
/* IEEE FP exception */
int code = 0;
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
-- Debut du message initial --- De : [EMAIL PROTECTED] A : [EMAIL PROTECTED] Copies : xenomai-core@gna.org Date : Tue, 26 Sep 2006 16:21:18 +0200 Objet : Re: [Xenomai-core] Problem with periodic timer on PPC40x solved On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote: Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum: On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote: Niklaus Giger wrote: .. Is the output of lines like Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) harmless or the result of a activated CONFIG_XENO_OPT_DEBUG.. option? A known hw issue seems to exist with the 405GP (revD), which causes the ESR to be incorrectly set upon FPU emulation trap, which would in turn cause the spurious exception to be relayed to the nucleus by Adeos. The patch below is _not_ the final fix, but rather a way to check if this message is indeed related to the FPU emulation on your board. Does it silence the exception without breaking the box? The FPU fault may be the result of the latency display thread using the FPU: on systems with emulated FPU, this looks normal. -- Gilles Chanteperdrix Accédez au courrier électronique de La Poste sur www.laposte.net ou sur 3615 LAPOSTENET (0,34 TTC /mn) 1 Giga de stockage gratuit Antispam et antivirus intégrés ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote: -- Debut du message initial --- De : [EMAIL PROTECTED] A : [EMAIL PROTECTED] Copies : xenomai-core@gna.org Date : Tue, 26 Sep 2006 16:21:18 +0200 Objet : Re: [Xenomai-core] Problem with periodic timer on PPC40x solved On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote: Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum: On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote: Niklaus Giger wrote: .. Is the output of lines like Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) harmless or the result of a activated CONFIG_XENO_OPT_DEBUG.. option? A known hw issue seems to exist with the 405GP (revD), which causes the ESR to be incorrectly set upon FPU emulation trap, which would in turn cause the spurious exception to be relayed to the nucleus by Adeos. The patch below is _not_ the final fix, but rather a way to check if this message is indeed related to the FPU emulation on your board. Does it silence the exception without breaking the box? The FPU fault may be the result of the latency display thread using the FPU: on systems with emulated FPU, this looks normal. This said, we should not switch the task to secondary mode, but rather emulate the FPU ops in primary mode. To this end, we need to make sure that do_mathemu() is not going to choke over this context (e.g. preemption count check issues over CONFIG_PREEMPT when running unmodified uaccess routines). We additionally need to fix the program check exception handler to give the math emulation code a chance to handle the fault before we complain loudly at the nucleus. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Philippe Gerum wrote: On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote: -- Debut du message initial --- De : [EMAIL PROTECTED] A : [EMAIL PROTECTED] Copies : xenomai-core@gna.org Date : Tue, 26 Sep 2006 16:21:18 +0200 Objet : Re: [Xenomai-core] Problem with periodic timer on PPC40x solved On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote: Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum: On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote: Niklaus Giger wrote: .. Is the output of lines like Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) harmless or the result of a activated CONFIG_XENO_OPT_DEBUG.. option? A known hw issue seems to exist with the 405GP (revD), which causes the ESR to be incorrectly set upon FPU emulation trap, which would in turn cause the spurious exception to be relayed to the nucleus by Adeos. The patch below is _not_ the final fix, but rather a way to check if this message is indeed related to the FPU emulation on your board. Does it silence the exception without breaking the box? The FPU fault may be the result of the latency display thread using the FPU: on systems with emulated FPU, this looks normal. This said, we should not switch the task to secondary mode, but rather emulate the FPU ops in primary mode. To this end, we need to make sure that do_mathemu() is not going to choke over this context (e.g. preemption count check issues over CONFIG_PREEMPT when running unmodified uaccess routines). We additionally need to fix the program check exception handler to give the math emulation code a chance to handle the fault before we complain loudly at the nucleus. OK, but in general, soft-float emulation should be used on systems without FPU and this is even more important for real-time. This is a tool chain issue. Niklaus, what tool chain are you using? Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
On Tue, 2006-09-26 at 18:28 +0200, Wolfgang Grandegger wrote: Philippe Gerum wrote: On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote: -- Debut du message initial --- De : [EMAIL PROTECTED] A : [EMAIL PROTECTED] Copies : xenomai-core@gna.org Date : Tue, 26 Sep 2006 16:21:18 +0200 Objet : Re: [Xenomai-core] Problem with periodic timer on PPC40x solved On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote: Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum: On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote: Niklaus Giger wrote: .. Is the output of lines like Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) harmless or the result of a activated CONFIG_XENO_OPT_DEBUG.. option? A known hw issue seems to exist with the 405GP (revD), which causes the ESR to be incorrectly set upon FPU emulation trap, which would in turn cause the spurious exception to be relayed to the nucleus by Adeos. The patch below is _not_ the final fix, but rather a way to check if this message is indeed related to the FPU emulation on your board. Does it silence the exception without breaking the box? The FPU fault may be the result of the latency display thread using the FPU: on systems with emulated FPU, this looks normal. This said, we should not switch the task to secondary mode, but rather emulate the FPU ops in primary mode. To this end, we need to make sure that do_mathemu() is not going to choke over this context (e.g. preemption count check issues over CONFIG_PREEMPT when running unmodified uaccess routines). We additionally need to fix the program check exception handler to give the math emulation code a chance to handle the fault before we complain loudly at the nucleus. OK, but in general, soft-float emulation should be used on systems without FPU and this is even more important for real-time. Makes sense. So maybe we should make this a more explicit and formal warning, to catch missing soft float emulation, actually. This is a tool chain issue. Niklaus, what tool chain are you using? Wolfgang. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Philippe Gerum wrote: On Tue, 2006-09-26 at 18:28 +0200, Wolfgang Grandegger wrote: Philippe Gerum wrote: On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote: -- Debut du message initial --- De : [EMAIL PROTECTED] A : [EMAIL PROTECTED] Copies : xenomai-core@gna.org Date : Tue, 26 Sep 2006 16:21:18 +0200 Objet : Re: [Xenomai-core] Problem with periodic timer on PPC40x solved On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote: Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum: On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote: Niklaus Giger wrote: .. Is the output of lines like Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) harmless or the result of a activated CONFIG_XENO_OPT_DEBUG.. option? A known hw issue seems to exist with the 405GP (revD), which causes the ESR to be incorrectly set upon FPU emulation trap, which would in turn cause the spurious exception to be relayed to the nucleus by Adeos. The patch below is _not_ the final fix, but rather a way to check if this message is indeed related to the FPU emulation on your board. Does it silence the exception without breaking the box? The FPU fault may be the result of the latency display thread using the FPU: on systems with emulated FPU, this looks normal. This said, we should not switch the task to secondary mode, but rather emulate the FPU ops in primary mode. To this end, we need to make sure that do_mathemu() is not going to choke over this context (e.g. preemption count check issues over CONFIG_PREEMPT when running unmodified uaccess routines). We additionally need to fix the program check exception handler to give the math emulation code a chance to handle the fault before we complain loudly at the nucleus. OK, but in general, soft-float emulation should be used on systems without FPU and this is even more important for real-time. Makes sense. So maybe we should make this a more explicit and formal warning, to catch missing soft float emulation, actually. We could already print a compiler warning when the kernel is built with MATH_EMULATION=y. There are a few corner-case where it might make sense to have math emulation enabled e.g. you need to run a binary with hard FP instructions because you are unable to rebuild it from the sources. This is a tool chain issue. Niklaus, what tool chain are you using? Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Am Dienstag, 26. September 2006 16:21 schrieb Philippe Gerum:
On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote:
Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum:
On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote:
Niklaus Giger wrote:
..
Is the output of lines like Xenomai: Switching display-3238 to
secondary mode after exception #1025 from user-space at 0x100033c4
(pid 3240) harmless or the result of a activated
CONFIG_XENO_OPT_DEBUG.. option?
A known hw issue seems to exist with the 405GP (revD), which causes the
ESR to be incorrectly set upon FPU emulation trap, which would in turn
cause the spurious exception to be relayed to the nucleus by Adeos. The
patch below is _not_ the final fix, but rather a way to check if this
message is indeed related to the FPU emulation on your board. Does it
silence the exception without breaking the box?
--- arch/ppc/kernel/traps.c~ 2006-09-25 17:10:48.0 +0200
+++ arch/ppc/kernel/traps.c 2006-09-26 16:14:30.0 +0200
@@ -638,9 +638,6 @@
unsigned int reason = get_reason(regs);
extern int do_mathemu(struct pt_regs *regs);
- if (ipipe_trap_notify(IPIPE_TRAP_PCE,regs))
- return;
-
#ifdef CONFIG_MATH_EMULATION
/* (reason REASON_ILLEGAL) would be the obvious thing here,
* but there seems to be a hardware bug on the 405GP (RevD)
@@ -655,6 +652,9 @@
}
#endif /* CONFIG_MATH_EMULATION */
+ if (ipipe_trap_notify(IPIPE_TRAP_PCE,regs))
+ return;
+
if (reason REASON_FP) {
/* IEEE FP exception */
int code = 0;
Tried your patch against adeos-ipipe 1.3. But I still get the same behaviour.
Here is my proc/cpuinfo.
$ cat /proc/cpuinfo
processor : 0
cpu : 405GPr
clock : 400MHz
revision: 9.81 (pvr 5091 0951)
bogomips: 398.33
machine : Netstal HCU3
plb bus clock : 133MHz
U-Boot printed the following info:
CPU: AMCC PowerPC 405GPr Rev. B at 400 MHz (PLB=133, OPB=33, EBC=33 MHz)
, PCI sync clock at 33 MHz 16 kB I-Cache 16 kB D-Cache
Best regards
--
Niklaus Giger
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Am Dienstag, 26. September 2006 18:28 schrieb Wolfgang Grandegger: Philippe Gerum wrote: On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote: OK, but in general, soft-float emulation should be used on systems without FPU and this is even more important for real-time. This is a tool chain issue. Niklaus, what tool chain are you using? In my .config I have MATH_EMULATION=y The toolchain is gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu built using Dan Kegel crosstool (Version 0.42 if I remember exactly). Shall I switch to another one? -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Here is the stack with adeos-ipipe 1.3 after applying your patch (gdb) info stack #0 xnpod_fault_handler (fltinfo=0xc1489e18) at kernel/xenomai/nucleus/pod.c:216 #1 0xc004bad4 in xnpod_trap_fault (fltinfo=0x73) at kernel/xenomai/nucleus/pod.c:2907 #2 0xc0043ee8 in xnarch_trap_fault (event=115, domid=0, data=0xc01a9435) at include/asm/xenomai/bits/init.h:46 #3 0xc012dc38 in exception_event (event=3223286668, ipd=0x0, data=0xc01a9435) at arch/ppc/xenomai/hal.c:385 #4 0xc003fe18 in __ipipe_dispatch_event (event=0, data=0xc1489f50) at kernel/ipipe/core.c:665 #5 0xc000aecc in do_page_fault (regs=0xc1489f50, address=268448708, error_code=0) at include/linux/ipipe.h:445 #6 0xc0003258 in handle_page_fault () Previous frame inner to this frame (corrupt stack?) (gdb) Hope it helps you -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
On Tue, 2006-09-26 at 21:34 +0200, Niklaus Giger wrote: Here is the stack with adeos-ipipe 1.3 after applying your patch (gdb) info stack #0 xnpod_fault_handler (fltinfo=0xc1489e18) at kernel/xenomai/nucleus/pod.c:216 #1 0xc004bad4 in xnpod_trap_fault (fltinfo=0x73) at kernel/xenomai/nucleus/pod.c:2907 #2 0xc0043ee8 in xnarch_trap_fault (event=115, domid=0, data=0xc01a9435) at include/asm/xenomai/bits/init.h:46 #3 0xc012dc38 in exception_event (event=3223286668, ipd=0x0, data=0xc01a9435) at arch/ppc/xenomai/hal.c:385 #4 0xc003fe18 in __ipipe_dispatch_event (event=0, data=0xc1489f50) at kernel/ipipe/core.c:665 #5 0xc000aecc in do_page_fault (regs=0xc1489f50, address=268448708, error_code=0) at include/linux/ipipe.h:445 #6 0xc0003258 in handle_page_fault () The function parameters look weird, but the backtrace seems ok. This tells us that it's not related to FPU emulation, but rather to an invalid memory access. Previous frame inner to this frame (corrupt stack?) (gdb) Hope it helps you -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum: On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote: Niklaus Giger wrote: .. Ok, we can go for the lazy fix here, since this code is poised to disappear anyway. I've merged a variant of the above we already use for the ARM port, which scales down the period to microseconds instead of losing precision on the count of timebase ticks per jiffy. - ticks = ns * tb_ticks_per_jiffy / (10 / HZ); + ticks = (ns / 1000) * tb_ticks_per_jiffy / (100 / HZ); Thanks for finding this solution. I tried to understand mulhwu and mulhwu_scale_factor but couldn't figure out a correct solution in a short time. The buildbot cannot presently power on and off my PPC405 target board, as the my power outlet switching device is broken and has been sent back for a remplacement. I did however run some tests manually and have the following questions about the output: Why do I get negative values for latenciy values? Is the output of lines like Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) harmless or the result of a activated CONFIG_XENO_OPT_DEBUG.. option? Mon Sep 25 20:20:33 UTC 2006 running: ./run -- -T 5 -t2 # latency * * * Type ^C to stop this application. * Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) == Sampling period: 100 us == Test mode: in-kernel timer handler == All results in microseconds warming up... RTT| 00:00:01 (in-kernel timer handler, 100 us period, priority 99) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD| -5.108| -4.754| -0.905| 0| -5.108| -0.905 RTD| -4.963| -4.871| 1.155| 0| -5.108| 1.155 Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0xfda9638 (pid 3240) RTD| -4.963| -4.758| 16.020| 0| -5.108| 16.020 RTD| -6.313| -4.861| 10.980| 0| -6.313| 16.020 Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0xfe7c1c4 (pid 3240) ---|||||- RTS| -6.313| -4.811| 16.020| 0|00:00:05/00:00:05 Xenomai: stopping RTDM services. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
