Re: [Xenomai-core] Problem with periodic timer on PPC40x solved

2006-09-28 Thread Niklaus Giger
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

2006-09-28 Thread Wolfgang Grandegger

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

2006-09-27 Thread Wolfgang Grandegger

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

2006-09-27 Thread Wolfgang Grandegger

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

2006-09-26 Thread Wolfgang Grandegger

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

2006-09-26 Thread Philippe Gerum
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

2006-09-26 Thread 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;
-- 
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

2006-09-26 Thread gilles\.chanteperdrix
-- 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

2006-09-26 Thread Philippe Gerum
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

2006-09-26 Thread Wolfgang Grandegger

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

2006-09-26 Thread Philippe Gerum
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

2006-09-26 Thread Wolfgang Grandegger

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

2006-09-26 Thread Niklaus Giger
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

2006-09-26 Thread Niklaus Giger
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

2006-09-26 Thread Niklaus Giger
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

2006-09-26 Thread Philippe Gerum
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

2006-09-25 Thread Niklaus Giger
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