On 5/7/10, Luca Niccoli <lultimou...@gmail.com> wrote: > On 7 May 2010 10:58, Thibaut Paumard <mlotpot.n...@free.fr> wrote: > > This is the info I got from Stephen Gran on d-admin: > > > > Processor : Feroceon rev 0 (v5l) > $ cat /proc/cpuinfo > > Processor : Feroceon 88FR131 rev 1 (v5l) > > Processor bug that was corrected in a later revision?
A search for "Feroceon rev" turns up a different theory: http://old.nabble.com/Re:-gcl-and-reverse-dependencies-on-arm-td27347704.html which suggests that it may be an old-ABI kernel system call or an unemulated FPA floating point instruction) that would not fail on machines with standard Debian kernels, which have old-ABI emulation and FPA emulation) enabled. A quick grep in the source turns up play/unix/fpuset.c:332 #elif defined(FPU_GCC_ARM) void u_fpu_setup(int when) { if (when <= 0) { unsigned int fpucw = 0x70200; __asm__ ("wfs %0" : : "r" (fpucw)); /* includes bit to trap on signalling NaN (may affect libm behavior) */ } } #elif defined(FPU_IGNORE) void u_fpu_setup(int when) { } where "wfs" is an old FPA instruction. Unfortunately, the play/unix/config.sh chooses a GCC_FPU_* macro by testing whether this file compiles, not whether it runs. The change from arm to armel (old-ABI to EABI) dropped the use of hardfloat instructions for the FPA and switched to softfloat, also allowing the use of VFP or Maverick FPUs if the user recompiles the package with magic runes. A quick hack to remove the FPA instruction and just not handle signalling NaNs on armel is - #elif defined(FPU_GCC_ARM) + #elif defined(FPU_GCC_ARM) && !defined(__VFP_FP__) && !defined(__MAVERICK__) but a quick look at the compaint from the build log suggests that this removes all handling of SIGFPE, including the uses that don't depend on signalling NaNs. Maybe you have a better idea than me of what functionality yorick really needs from the FPU exceptions and how to find a better compromise. See http://wiki.debian.org/ArmEabiPort#GCCpreprocessormacrosforfloatingpoint for the non-obvious meaning of these defines (__VFP_FP__ does not mean you have a hardware VFP FPU, it is about floating point storage format) Other gurus may be able to suggest alternatives that will work when softfloat and/or VFP are selected. No one really cares about Maverick FPUs as they are more rare - I just mention it here to get the ifdef right. Sadly, the fenv(3) family of functions doesn't handle the signalling NaN exceptions, which is what yorick really needs here. Hope that helps M -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimtrctcofniz7vhhyxna7seaqcjjev3zglpz...@mail.gmail.com