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

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

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 n

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

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 cpuc

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