Hi Maciej, On 03/06/17 22:43, Maciej W. Rozycki wrote: > On Sat, 3 Jun 2017, Stuart Longland wrote: >> Now, on a single-processor MIPS64r2 VM, this same root filesystem works. >> It won't work though for a 8-core I6400 system. If I try to run a SMP >> MIPS64r2 VM, I get "unable to proceed without a CM", so clearly there is >> a feature in the I6400 that doesn't exist in the MIPS64r2. > > Your userland likely requires the legacy NaN encoding (as specified by > the IEEE 754-1985 floating point standard) whereas I6400 hardware only > supports the 2008 NaN encoding (as specified by the IEEE 754-2008 floating > point standard), as per the R6 architecture requirement. These encodings > are incompatible with each other and all binaries are annotated in their > ELF header as to which is required; use `readelf -h' and check `Flags:' > for the presence of `nan2008' among the features reported. Ahh, quite possible. I just compiled for MIPS III, not sure if that supports this alternate NaN encoding. The ultimate target for this is Loongson 2F which probably uses the old encoding. > There are a couple of ways to move forward. > > First is rebuilding your userland for the 2008 NaN encoding. I'm sure > someone already did it, but I don't have a pointer at hand. This might be > the best option however. This will be a lengthy process, is there a particular compiler flag I should be using for that? `man gcc` seems to mention the following: > -mabs=2008 > -mabs=legacy > These options control the treatment of the special not-a-number (NaN) IEEE 754 floating-point data with the "abs.fmt" and "neg.fmt" > machine instructions. > > By default or when -mabs=legacy is used the legacy treatment is selected. In this case these instructions are considered arithmetic and > avoided where correct operation is required and the input operand might be a NaN. A longer sequence of instructions that manipulate the > sign bit of floating-point datum manually is used instead unless the -ffinite-math-only option has also been specified. > > The -mabs=2008 option selects the IEEE 754-2008 treatment. In this case these instructions are considered non-arithmetic and therefore > operating correctly in all cases, including in particular where the input operand is a NaN. These instructions are therefore always used > for the respective operations. > > -mnan=2008 > -mnan=legacy > These options control the encoding of the special not-a-number (NaN) IEEE 754 floating-point data. > > The -mnan=legacy option selects the legacy encoding. In this case quiet NaNs (qNaNs) are denoted by the first bit of their trailing > significand field being 0, whereas signalling NaNs (sNaNs) are denoted by the first bit of their trailing significand field being 1. > > The -mnan=2008 option selects the IEEE 754-2008 encoding. In this case qNaNs are denoted by the first bit of their trailing significand > field being 1, whereas sNaNs are denoted by the first bit of their trailing significand field being 0. > > The default is -mnan=legacy unless GCC has been configured with --with-nan=2008. If I understand correctly, the right thing to do would be to use -mnan=2008 then? What's the effect on pre-2008 CPUs? > Second, since you're running on a simulator anyway, disabling the use of > FPU hardware and using the Linux kernel FPU emulator should have little > performance impact, although there surely be some for the Coprocessor > Unusable exception handling overhead. The Linux kernel FPU emulator > supports both NaN encodings at once, so any userland will work > irrespectively of which NaN encoding it requires and produce correct > results. Use the "nofpu" kernel parameter to activate this option. > > Finally, you might also ask the kernel to ignore the binary > incompatibility and let binaries requiring the wrong NaN encoding run > anyway. This will make IEEE 754 floating point produce incorrect results > in the uncommon case of software relying on NaN arithmetic; it may crash > for example. The vast majority of software does not rely on NaN > arithmetic though. Use the "ieee754=relaxed" kernel parameter to activate > this option. These might be options too… I'm basically just compiling software, so not an activity that is likely to produce NaNs or floating-point operations. The biggest bug bear right now is compiling `gcc` which is by far one of the biggest packages and seems to take days to compile. (gcc-5.4.0 takes at least 2 days… 6.3 takes even longer then fails to bootstrap). > You can have a look at Documentation/admin-guide/kernel-parameters.txt in > the kernel sources for some further discussion about these kernel > parameters. These will have to be added to the QEMU's `-append' command > line option. Will do, many thanks. :-) Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Attachment:
signature.asc
Description: OpenPGP digital signature
