gmane.os.netbsd.ports.x86-64

scalbn and scalbnf failure on amd64

Martin Husemann — 2013-05-20T14:29:22

If you do (in -current) something like:

  cd /usr/tests/lib/libm && atf-run t_scalbn | atf-report

you will get:

Failed test cases:
    t_scalbn:scalbn_ldexp, t_scalbn:scalbnf_ldexpf

Summary for 1 test programs:
    18 passed test cases.
    2 failed test cases.
    0 expected failed test cases.
    0 skipped test cases.

The failures in more detail show up if you only run "atf-run t_scalbn":

tc-se:*** Check failed: /usr/src/tests/lib/libm/t_scalbn.c:168: test 2: exponent=-1, y=inf, expected 1.45644 (diff: inf)
tc-se:*** Check failed: /usr/src/tests/lib/libm/t_scalbn.c:168: test 4: exponent=-100, y=inf, expected 2.29786e-30 (diff: inf)

and:

tc-se:*** Check failed: /usr/src/tests/lib/libm/t_scalbn.c:321: test 2: exponent=-1, y=1.45644 ldexpf returns inf (diff: -inf)
tc-se:*** Check failed: /usr/src/tests/lib/libm/t_scalbn.c:321: test 4: exponent=-100, y=2.29786e-30 ldexpf returns inf (diff: -inf)

which basically means that

   scalbnf(2.91288191221812821, -1)

as well as

   scalbnf(2.91288191221812821, -100)

return "inf". Same for scalbn().

This is wrong, and at least on my amd64 hardware 100% reproducable. I
can't spot the bug in src/lib/libm/arch/i387/s_scalbn.S (or
s_scalbnf.S) - anyone?

Martin

Re: Changing the default i387 precision (compiler float constant evaluation)

Dennis Ferguson — 2013-05-16T00:36:47

On 12 May, 2013, at 22:00 , Dennis Ferguson <dennis.c.ferguson< at >gmail.com> wrote:
[...]

Attached is a program to show the problems with C99 compliance and
general unhappiness caused by the current default setting of the x87
precision on NetBSD.  The program evaluates

    1 - ((4/x) - 1) * x

for x==3.0 both as a compile time constant and at run time, and can
be compiled to do so in any of the 3 floating point types.  In
exact arithmetic the result is precisely zero so the greater the
precision with which the expression is evaluated the closer to
zero the result should be.

Here are the results for amd64 and i386 gcc, with the program
compiled for each of the 3 floating point types and with the standard
set to C99:

  $ gcc -std=c99 -DFLOAT -O -o try try.c
  $ ./try
  (8 0 4 1.19209e-07):  compiler = -1.19209e-07  run_time = -1.19209e-07
  $ gcc -std=c99 -DDOUBLE -O -o try try.c
  $ ./try
  (8 0 8 2.22045e-16):  compiler = 2.22045e-16  run_time = 2.22045e-16
  $ gcc -std=c99 -O -o try try.c
  $ ./try
  (8 0 16 1.08420e-19):  compiler = -1.08420e-19  run_time = 2.22045e-16
  $ gcc -m32 -std=c99 -DFLOAT -O -o try try.c
  $ ./try
  (4 2 4 1.19209e-07):  compiler = -1.08420e-19  run_time = 2.22045e-16
  $ gcc -m32 -std=c99 -DDOUBLE -O -o try try.c
  $ ./try
  (4 2 8 2.22045e-16):  compiler = -1.08420e-19  run_time = 2.22045e-16
  $ gcc -m32 -std=c99 -O -o try try.c
  $ ./try
  (4 2 12 1.08420e-19):  compiler = -1.08420e-19  run_time = 2.22045e-16

The values in (...) are sizeof(long), FLT_EVAL_METHOD, sizeof(floating_type)
used for the evaluation and XXX_EPSILON for floating_type.  Results closer
to 0 are more precise.  Any result which is significantly larger in magnitude
than XXX_EPSILON has been computed with less than the precision claimed for
the type; this is the case for amd64 and i386 long double computations, and
would be fixed by changing the default i387 precision.  All the i386
compiler-evaluated results are consistent with the FLT_EVAL_METHOD of 2,
and the value of LDBL_EPSILON, but the run time results are not.  Note
that while the letter of the C standard allows compile-time evaluation
of constant floating point expressions to be performed more precisely than
the run time, as is the case for the above i386 behaviour, it is
always better if the compile-time and execution-time evaluations match
precisely since that avoids having the results produced by a floating point
programs change with the optimization level due to this, which in turn makes
it easier to find real problems caused by the compiler's optimizer.  Changing the
default x87 precision to that of the 10-byte IEEE 754 format would make
the C99 compile-time and run-time behaviour fully consistent, and would
make the behaviour match the C99 standard where it does not now.

All of this makes perfect sense to me.  The only thing I don't get is that,
while the compiler clearly knows how it is supposed to behave for standard
C, by default it apparently instead provides "GNU" C with the following
behaviour for i386:

  $ gcc -m32 -std=gnu99 -DFLOAT -o try try.c
  $ ./try
  (4 2 4 1.19209e-07):  compiler = -1.19209e-07  run_time = 2.22045e-16
  $ gcc -m32 -std=gnu99 -DDOUBLE -o try try.c
  $ ./try
  (4 2 8 2.22045e-16):  compiler = 2.22045e-16  run_time = 2.22045e-16
  $ gcc -m32 -std=gnu99 -o try try.c
  $ ./try
  (4 2 12 1.08420e-19):  compiler = -1.08420e-19  run_time = 2.22045e-16

This does not provide an argument against changing the x87 precision since
no setting of the x87 precision is going to be consistent with that and,
given this, it is still better to set the x87 to fix long double and produce
better arithmetic in general.  I just don't get why it does that.

In any case, I think changing the x87 precision to that of the 10-byte
IEEE 754 extended format is exactly the right thing to do.  The current
state breaks long double on both architectures and is inconsistent with
a standard compiler for all three floating point types for i386.

Dennis Ferguson

Re: Changing the default i387 precision

Joerg Sonnenberger — 2013-05-06T12:13:10

Almost noone wants to have IEEE754 behavior with i387. It is hideously
expensive. We don't provide it at the moment either, since e.g.
underflows don't happen at the correct time. Setting the default
rounding precision fixes the behavior of some operations and leaves
others intact. There is no work around for that. As I said before, the
only real way to get IEEE754 float and double behavior with decent
performance (and frankly, decent performance in general) is to use SSE.

Joerg

Re: Changing the default i387 precision

Joerg Sonnenberger — 2013-05-04T17:11:07

The default rounding mode to give full internal precision.

Joerg

Re: Changing the default i387 precision

Joerg Sonnenberger — 2013-05-04T13:07:06

ISO C99 specifies rules on when the compiler is allowed to use a higher
precision for intermediate values and when not. That includes macros for
deciding what types the math is done in. We get away with our hack
mostly because underflow/overflow are rare enough that the larger
exponent is not visible. See also -ffloat-store and
-fexcess-precision=standard.

Joerg

Re: Changing the default i387 precision

Greg Troxel — 2013-05-04T12:50:29

Joerg Sonnenberger <joerg< at >britannica.bec.de> writes:


If what you want to do now is to change the way rounding is handled so
that:

   long double variables get the 80-bit precision

without

   making (non-long) doubles get results that don't comply with IEEE754
   (by using extended precision intermedate values)

then that sounds fine.  But I can't really tell what you want to change.

Re: Changing the default i387 precision

Greg Troxel — 2013-05-04T11:14:00

If I follow the standards and your mail correctly:

  C99 says "long double" does not necessarily map to an IEEE754 type.

  While enforcing IEEE754-compliant rounding on "double" makes sense, I
  don't understand it on long double.

  You are talking about the 80-bit x86 extended double format as 'long
  double'?

  To have 'proper long double support' in libm, means functions with
  long double type signature that take these 80-bit quantities and
  operate on them?

  Most compilers use SSE when the code says long double, but SSE/SSE2 is
  only regular double.

  C99 defines eg "cosl" that takes and returns long double.

  Fortunately we have no system calls with long doubles, so there are no
  issues there.

So are you proposing then

  1) Make gcc and clang use larger storage (maybe already true) and avoid
  SSE instructions for variables declared as long double?

  2) Add functions in libm so that instead of float/double versions we
  will have float/double/long double versions of each function?

I'm not sure that this leads to a lot of incremental usefulness, and
it's a fair bit of work.  But from the standards-weenie view I don't see
anything wrong with doing it.

Changing the default i387 precision

Joerg Sonnenberger — 2013-05-04T02:44:48

Hi all,
one of the missing parts of our libm is proper long double support for
x86. This is somewhat complicated by the fact that our long double is
castrated by the default rounding to 53bit (a.k.a. double) mantissa
size. The historic reason is that forcing double rounding in code that
needs the precision to be exact requires care and in theory, it might
change results of code that doesn't expect it. Given that Linux and
FreeBSD default to the whole mantissa, I doubt that the second argument
is valid. It doesn't normally apply to amd64 anyway, since most
compilers will default to the faster SSE units for double arithmetic
anyway. This leads to the important question of whether we want to have
real long double or not. Opinions?

Joerg

Re: port-amd64/47782 - ifconfig SIOCSIFMEDIA error with bge

Jeff Rizzo — 2013-05-02T17:36:55

This might prove very tricky to do; 6.1_RC4 was just released, and 6.1 
proper should be out within two weeks.  *Possibly* if this is a small, 
non-risky change.  (Luckily, I have some bge(4) boxes to do a little 
testing on)

Otherwise, there's always 6.2!

+j

Re: port-amd64/47782 - ifconfig SIOCSIFMEDIA error with bge

STEPHEN JONES — 2013-05-02T05:51:46

On May 1, 2013, at 7:51 PM, Masanobu SAITOH wrote:


Masa has clarified this as an issue specific the IPMI for the onboard devices on the
H8SSL (SuperMicro) and likely other boards.  I saw this behavior in 5.x testing as well,
but it looks like it has been addressed in -current.  Running 6.99.19 on the same host
showed the bge driver to be robust.  If possible, it would be great to have the -current
bge code, if it is not too extensive of a change, in the pending release of 6.1.  

Thank you for your clarification and help with this issue.

Re: port-amd64/47782 - ifconfig SIOCSIFMEDIA error with bge

Masanobu SAITOH — 2013-05-02T02:51:54

  Could you show me the full dmesg of the machine with BGE_DEBUG option?

port-amd64/47782 - ifconfig SIOCSIFMEDIA error with bge

Stephen M. Jones — 2013-05-01T17:47:06

Just a quick follow up to port-amd64/47782

I did a fresh install on several SuperMicro amd64 servers with bge ethernet
interfaces and configured both bge's in an acceptable fashion.  I then clean
booted the servers 865 times to gather some stats.

Background:  I'm using NetBSD ukato 6.0.1 NetBSD 6.0.1 (GENERIC) amd64.  I
was using a custom kernel with bge/brgphy, but thought for this test using
generic would be best.

ifconfig.bge0:
up
media autoselect
192.94.73.7 netmask 0xffffff00 media autoselect

ifconfig.bge1:
up
media autoselect
10.0.0.7 netmask 0xffffff00 media autoselect

bge1 always had its interface successfully configured.  However, bge0
failed with an ifconfig: SIOCSIFMEDIA: Invalid argument 343 times, but was
successful 522 times (total of 865 clean boots).

For media and mediaopts I did implicitly set those, but still ran into issues
with bge0 failing iwth a SIOCSIFMEDIA.  When the interface is in this state,
you cannot even do a simple ifconfig bge0 192.94.73.7 to bring the interface
up even by doing a ksh /etc/rc.d/network stop first.  I believe that this
is likely a serious bug.  Originally I thought that this may be an autoneg
issue with the switch, but simple ifconfigs are failing without a reboot.

However, if I'm overlooking something that has changed between NetBSD 4.0.1 
and 6.x, please feel free to stick my nose in it.

Re: x86 pcitag_t change proposal/patch

Jonathan A. Kollasch — 2013-04-26T14:44:23

I've been sitting on a revised pcitag_t adjustment patch for months,
it can be found attached.

I should point out - for the naysayers that think having the BDF in bits
23-8 is better - on x86 there are dedicated sub-registers for accessing
bits 15-0, 15-8, and 7-0 of a register word, while there are not for
bits 23-16 or 31-16, so it turns out that putting the B:DF in bits
15-8:7-0 works out pretty well for elegant and compact generated
assembly code.

Also, my thought is, that if we ever have to use the 16-bit PCI domain
number from ACPI, that we can stuff it in bits 31-16 of the pcitag_t,
rather than have the complexity of introducing a chipset tag for each
domain.

Anyway (assuming nothing more important comes up) I'd be happy to resume
work on using the ACPI MCFG info for config space access today.

Jonathan Kollasch

Re: x86 pcitag_t change proposal/patch

Masanobu SAITOH — 2013-04-26T02:16:22

Hi, Jonathan

(2012/12/05 11:59), Jonathan A. Kollasch wrote:

  What's the current status of this work? I'd like to access to the PCIe
extended configuration space (from 0x100 to 0xfff) for debugging purpose.
There are a lot of important informations in it...

Intermittent SpeedStep?

Mouse — 2013-03-07T01:14:14

I have a machine I'm running amd64 5.2 on.  It is apparently
SpeedStep-capable, but only intermittently.  I've set up code to record
boot-time messages (via /var/run/dmesg.boot) on each boot.  It's a
relatively mobile machine, so it gets rebooted frequently.  And I see
SpeedStep appearing only sometimes.

For example, the boot of 2013-03-05 04:41:33 shows

cpu0 at mainbus0 apid 0: Intel 686-class, 2493MHz, id 0x10676
cpu1 at mainbus0 apid 1: Intel 686-class, 2493MHz, id 0x10676

but the boots of 2013-03-05 12:44:12 and 2013-03-06 18:33:30 showed

cpu0 at mainbus0 apid 0: Intel 686-class, 2493MHz, id 0x10676
cpu0: Enhanced SpeedStep (1068 mV) 600 MHz
cpu0: Enhanced SpeedStep frequencies available (MHz): 7600 7000 6400 5700 5100 4500 3800 3200 2600 1900 1300 700
cpu1 at mainbus0 apid 1: Intel 686-class, 2493MHz, id 0x10676

Any idea what could be behind this intermittent presence?  Even without
a complete answer to that, is there anything I can do to make it work
more often?

In case it helps, here's what cpuctl identify 0 has to say:

cpu0: Intel Core 2 Extreme (686-class), 2493.94 MHz, id 0x10676
cpu0: features 0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features 0xbfebfbff<PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX>
cpu0: features 0xbfebfbff<FXSR,SSE,SSE2,SS,HTT,TM,SBF>
cpu0: features2 0x8e3bd<SSE3,DTES64,MONITOR,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE41>
cpu0: features3 0x20100800<SYSCALL/SYSRET,XD,EM64T>
cpu0: "Intel(R) Core(TM)2 Duo CPU     T9300  < at > 2.50GHz"
cpu0: I-cache 32KB 64B/line 8-way, D-cache 32KB 64B/line 8-way
cpu0: L2 cache 6MB 64B/line 24-way
cpu0: ITLB 128 4KB entries 4-way
cpu0: DTLB 256 4KB entries 4-way, 16 4MB entries 4-way
cpu0: Initial APIC ID 0
cpu0: Cluster/Package ID 0
cpu0: Core ID 0
cpu0: family 06 model 07 extfamily 00 extmodel 01 stepping 06

In passing, I note that the SpeedStep sysctl tree under machdep.est
does not have anywhere in the MIB to stick a CPU number.  Is it not
hardwarily possible to have different CPUs SpeedStepped to different
frequencies, or the software support just isn't there yet, or what?

/~\ The ASCII  Mouse
\ / Ribbon Campaign
 X  Against HTMLmouse< at >rodents-montreal.org
/ \ Email!     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Does that work? Intel C204 PCH Chipset on /AMD

Jean-Yves Migeon — 2013-02-21T13:27:29

Le 21/02/2013 13:57, Markus Illenseer a écrit :

Not to my knowledge. I would check peripherals though, you can have a 
working chipset and CPU but without a working driver for the NIC or HD 
controller.

Nowadays most 32 bits systems I encounter run with PAE, and when 
considering 64 bits or 32 bits PAE I would still prefer 64 bits. PAE 
support requires some hacks here and there in the kernel.

As for benchmarks 32 bits and 64 bits are on par. PAE is slightly 
slower.


Fair enough. Sadly I have no MB with that chipset, so I cannot really 
tell :/


There is no real difference. 64 bits has an added benefit though, you 
can run 32 bits and 64 bits binaries, while i386 only allows you to run 
32 bits code. That will not affect chipset support anyway.

Cheers,

Re: Does that work? Intel C204 PCH Chipset on /AMD

Martin Husemann — 2013-02-21T13:14:01

Not in general. I run both pretty heavily on various machines (and even
an i386 xen guest with PAE) and see no noticable differences when it comes
to stability.

There are a few subtle differences though, like pkgrc (and some
in-tree) software is allowed to assume things like SSE2 on the amd64
port, but not on all cpus supported by i386, so compiler flags are
better tuned by default (see Xorg and pixman for example).

So what Yves said: depends heavily on your application.

Sorry, can't tell you anything concrete about the exact system you asked.

Martin

Re: Does that work? Intel C204 PCH Chipset on /AMD

Markus Illenseer — 2013-02-21T12:57:35

Hi there.



More in the sense of stability, crashes, reliability. Does it perform or 
not. Are there known issues. No comparison evolved.



I don't want to buy the system and then find out, NetBSD wouldn't run or 
does crash due to issues with the chip set.


Yes of course. I was under the impression, NetBSD/AMD is more stable than 
NetBSD/x86 anyway?


--
Markus Illenseer

Re: Does that work? Intel C204 PCH Chipset on /AMD

Jean-Yves Migeon — 2013-02-21T12:44:31

Le 20/02/2013 08:49, Markus Illenseer a écrit :

When compared to what? 32 bits?


IMHO the fastest way to check would be an CD/DVD boot or USB.

The rest depends heavily on the application you run (I am not sure that 
32 bits applications will benefit much from running on amd64, except 
that you may run more of them...)

Does that work? Intel C204 PCH Chipset on /AMD

Markus Illenseer — 2013-02-20T07:49:37

Hello dear NetBSD/AMD-supporters,

I am currently evaluating whether I can switch to a server with a 
chipset "Intel C204 PCH Chipset" running NetBSD/AMD with 64Bit support.
Mainboard would be a "Supermicro X9SCM-F" with "Intel Xeon E3-1200" CPU.

Are there any contras on running such a system (apart speed, the server 
is for personal use)?

Please answer with Cc to me, I am currently not subscribed.

Thanks!

--
Markus Illenseer

Re: 32bit linux emulation on amd64

Ignatios Souvatzis — 2013-02-20T19:37:47

Hi,

On Tue, Feb 19, 2013 at 02:40:00PM +0100, is< at >netbsd.org wrote:


... is true again, after I built a kernel without a certain experimental
vmparam.h change I had in my tree.

Sorry for the noise.

-is