Re: llvm ld vs binutils ld

[Steve Kargl]

On Fri, Feb 02, 2024 at 10:48:54PM +0200, Konstantin Belousov wrote:
> On Fri, Feb 02, 2024 at 12:07:35PM -0800, Steve Kargl wrote:
> > 
> > Thanks for the explanation, but I think I now have a conundrum.
> > Suppose I have two shared libraries libfoo.so and libbar.so, and
> > suppose bah@@XXX_1.0 is in libbar.so's symbol map.  If my main
> > program uses bah() and I compile with 'cc -o z main.c -lfoo -lbar',
> > then the linker finds bah@XXX_1.0.
> > 
> > Now suppose a developer adds a new procedure to libfoo.so and she
> > just so happens to name her new function bah() with a symbol map
> > entry of bah@YYY_a.b.
> > 
> > Which bah@ is linked when rebuilding or loading 'z'?  Does it
> > depend on the search order for ld-config.so.1?
> 
> In the 'z' binary either bah@XXX_1.0 or bah@YYY_1.0 is specified as
> the symbol to resolve at the call site. Dynamic linker searches for
> corresponding versioned symbol in the global namespace, typically.
> 
> So now the question is reduced to what version of the symbol bah get
> recorded into the 'z' binary.  It is done by static linker, which looks
> up symbols linearly in the order of object files and libraries specified
> on the command line (*).  If you did 'cc -o z main.c -lfoo -lbar', and
> both libfoo.so and libbar.so provided the bah symbol, the first found
> definition is recorded, together with its version.  The final answer
> is lookup finds bah in libfoo.so and bah@YYY_1.0 is recorded.
> 
> * There are many ways to direct static linker to find specific version
> of the symbol, changing the default behavior.

Thank you.  This essentially confirms my fears.  

-- 
Steve

Re: llvm ld vs binutils ld

[Steve Kargl]

On Sun, Jan 28, 2024 at 12:04:48PM +0200, Konstantin Belousov wrote:
> On Sat, Jan 27, 2024 at 09:22:59PM -0800, Steve Kargl wrote:
> > On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote:
> > > On 27 Jan 2024, at 18:08, Steve Kargl  
> > > wrote:
> > > > 
> > > > In an attempt to cleanup a bit of src/lib/msun, I ran into
> > > > a small issue that I cannot explain at the moment.  If I have
> > > > /usr/bin/ld in my path prior to /usr/local/bin/ld everything
> > > > works
> > > > 
> > > > % which ld
> > > > /usr/bin/ld
> > > > % make clean && make cleandepend
> > > > % make
> > > > 
> > > > and I have a libm.so.5.  But if /usr/local/bin/ld is found, I
> > > > see
> > > > 
> > > > % cd msun
> > > > % make clean && make cleandepend
> > > > % make
> > > > ..
> > > > ld: error: version script assignment of 'FBSD_1.0' to symbol 'fabs' \
> > > >failed: symbol not defined
> > > > cc: error: linker command failed with exit code 1 (use -v to see 
> > > > invocation)
> > > > *** Error code 1
> > > > 
> > > > Stop.
> > > > make: stopped in /usr/src/lib/msun
> > > > 
> > > > % grep fabs /usr/src/lib/msun/Symbol.map 
> > > >fabs;
> > > >fabsf;
> > > >fabsl;
> > > > 
> > > > But, if one looks in msun/Makefile, one see
> > > > 
> > > > # FreeBSD's C library supplies these functions:
> > > > #COMMON_SRCS+=  s_fabs.c s_frexp.c s_isnan.c s_ldexp.c s_modf.c
> > > > 
> > > > so fabs is not built with libm.  
> > > > 
> > > > % nm --dynamic /lib/libc.so.7 | grep fabs
> > > > 000ba600 T fabs
> > > > % nm --dynamic /lib/libm.so.5 | grep fabs
> > > > 0001fa90 T fabsf
> > > > 000252e0 T fabsl
> > > > 
> > > > 
> > > > Is this a known issue?  Should fabs be removed from Symbol.map?
> > > 
> > > Yes, fabs is excluded in msun's Makefile:
> > > 
> > > # FreeBSD's C library supplies these functions:
> > > #COMMON_SRCS+=  s_fabs.c s_frexp.c s_isnan.c s_ldexp.c s_modf.c
> > 
> > Thanks for the quick response.  I knew this, but
> > 
> > > so it should not have been in Symbol.map at all.
> > 
> > it has been this way for a very long time.  
> > 
> > > The comment is also
> > > incorrect, since s_frexp.c and s_isnan.c *are* actually in COMMON_SRCS,
> > > see lines 79 and 80 of the Makefile. (They are indeed also in libc, so
> > > which one is chosen is only known by the linker. :)
> > 
> > I would it depends on the search order of the libraries.  For
> > static linking, it's the order on the commandline.  For rtld,
> > it's the order of the libraries in the cache.
> > 
> > % nm --dynamic /lib/libc.so.7 | grep snan
> > 000ace30 T __isnan@@FBSD_1.0
> > 000ace60 T __isnanf@@FBSD_1.0
> > 000ace30 W isnan@@FBSD_1.0
> > 000ace60 W isnanf@@FBSD_1.0
> > % nm --dynamic /lib/libm.so.5  | grep snan
> > 000220a0 T __isnanf@@FBSD_1.2
> > 000220d0 T __isnanl@@FBSD_1.0
> > 000220a0 W isnanf@@FBSD_1.0
> > 
> > Not quite.  isnan is in libc but libm.  isnanf seems to be
> > in both, and isnanl is only in libm.  Does FBSD_1.2 trump
> > FBSD_1.0 for __isnanf?
> No, the binary specifies which version of the symbol it wants, either
> __isnanf@FBSD_1.2 or __isnanf@FBSD_1.0, and the dynamic linker binds to
> the version.
> 
> Which version is recorded into the consumer binary, is up to the static
> linker (ld), and there it is normally defined by the order of the libraries
> specified on the command line.

Thanks for the explanation, but I think I now have a conundrum.
Suppose I have two shared libraries libfoo.so and libbar.so, and
suppose bah@@XXX_1.0 is in libbar.so's symbol map.  If my main
program uses bah() and I compile with 'cc -o z main.c -lfoo -lbar',
then the linker finds bah@XXX_1.0.

Now suppose a developer adds a new procedure to libfoo.so and she
just so happens to name her new function bah() with a symbol map
entry of bah@YYY_a.b.

Which bah@ is linked when rebuilding or loading 'z'?  Does it
depend on the search order for ld-config.so.1?

-- 
Steve

Re: llvm ld vs binutils ld

[Steve Kargl]

On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote:
> On 27 Jan 2024, at 18:08, Steve Kargl  
> wrote:
> > 
> > In an attempt to cleanup a bit of src/lib/msun, I ran into
> > a small issue that I cannot explain at the moment.  If I have
> > /usr/bin/ld in my path prior to /usr/local/bin/ld everything
> > works
> > 
> > % which ld
> > /usr/bin/ld
> > % make clean && make cleandepend
> > % make
> > 
> > and I have a libm.so.5.  But if /usr/local/bin/ld is found, I
> > see
> > 
> > % cd msun
> > % make clean && make cleandepend
> > % make
> > ..
> > ld: error: version script assignment of 'FBSD_1.0' to symbol 'fabs' \
> >failed: symbol not defined
> > cc: error: linker command failed with exit code 1 (use -v to see invocation)
> > *** Error code 1
> > 
> > Stop.
> > make: stopped in /usr/src/lib/msun
> > 
> > % grep fabs /usr/src/lib/msun/Symbol.map 
> >fabs;
> >fabsf;
> >fabsl;
> > 
> > But, if one looks in msun/Makefile, one see
> > 
> > # FreeBSD's C library supplies these functions:
> > #COMMON_SRCS+=  s_fabs.c s_frexp.c s_isnan.c s_ldexp.c s_modf.c
> > 
> > so fabs is not built with libm.  
> > 
> > % nm --dynamic /lib/libc.so.7 | grep fabs
> > 000ba600 T fabs
> > % nm --dynamic /lib/libm.so.5 | grep fabs
> > 0001fa90 T fabsf
> > 000252e0 T fabsl
> > 
> > 
> > Is this a known issue?  Should fabs be removed from Symbol.map?
> 
> Yes, fabs is excluded in msun's Makefile:
> 
> # FreeBSD's C library supplies these functions:
> #COMMON_SRCS+=  s_fabs.c s_frexp.c s_isnan.c s_ldexp.c s_modf.c

Thanks for the quick response.  I knew this, but

> so it should not have been in Symbol.map at all.

it has been this way for a very long time.  

> The comment is also
> incorrect, since s_frexp.c and s_isnan.c *are* actually in COMMON_SRCS,
> see lines 79 and 80 of the Makefile. (They are indeed also in libc, so
> which one is chosen is only known by the linker. :)

I would it depends on the search order of the libraries.  For
static linking, it's the order on the commandline.  For rtld,
it's the order of the libraries in the cache.

% nm --dynamic /lib/libc.so.7 | grep snan
000ace30 T __isnan@@FBSD_1.0
000ace60 T __isnanf@@FBSD_1.0
000ace30 W isnan@@FBSD_1.0
000ace60 W isnanf@@FBSD_1.0
% nm --dynamic /lib/libm.so.5  | grep snan
000220a0 T __isnanf@@FBSD_1.2
000220d0 T __isnanl@@FBSD_1.0
000220a0 W isnanf@@FBSD_1.0

Not quite.  isnan is in libc but libm.  isnanf seems to be
in both, and isnanl is only in libm.  Does FBSD_1.2 trump
FBSD_1.0 for __isnanf?

> It doesn't complain with lld >= 16 because of
> https://cgit.freebsd.org/src/commit/?id=2ba84b4bcdd60, where it add
> -Wl,--undefined-version to suppress such warnings. I added that rather
> big hammer to be able to continue importing llvm 16, but I see now that
> it may be better to attempt to fix all individual failures due to
> missing symbols.
> 
> The reason that it still goes wrong if you put /usr/local/bin in front
> of your PATH (or if you set LD explicitly to /usr/local/bin/ld) is that
> /usr/bin/cc will pick /usr/bin/ld over whatever it finds in the PATH or
> in the LD variable, while bsd.linker.mk still uses PATH or LD to find
> the linker type and version. E.g., it concludes that the linker type is
> BFD and the version is 2.40, then does not add the
> -Wl,--undefined-version to allow undefined symbols.

Thanks for the details.  This had me stumped.

-- 
Steve

llvm ld vs binutils ld

[Steve Kargl]

In an attempt to cleanup a bit of src/lib/msun, I ran into
a small issue that I cannot explain at the moment.  If I have
/usr/bin/ld in my path prior to /usr/local/bin/ld everything
works

% which ld
/usr/bin/ld
% make clean && make cleandepend
% make

and I have a libm.so.5.  But if /usr/local/bin/ld is found, I
see

% cd msun
% make clean && make cleandepend
% make
..
ld: error: version script assignment of 'FBSD_1.0' to symbol 'fabs' \
failed: symbol not defined
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Stop.
make: stopped in /usr/src/lib/msun

% grep fabs /usr/src/lib/msun/Symbol.map 
fabs;
fabsf;
fabsl;

But, if one looks in msun/Makefile, one see

# FreeBSD's C library supplies these functions:
#COMMON_SRCS+=  s_fabs.c s_frexp.c s_isnan.c s_ldexp.c s_modf.c

so fabs is not built with libm.  

% nm --dynamic /lib/libc.so.7 | grep fabs
000ba600 T fabs
% nm --dynamic /lib/libm.so.5 | grep fabs
0001fa90 T fabsf
000252e0 T fabsl


Is this a known issue?  Should fabs be removed from Symbol.map?


-- 
Steve

RCS and $FreeBSD$ purge

[Steve Kargl]

I'm currently syncing src/lib/msun with my private libm 
repository where I do much of my hacking on libm issues.
In looking at diffs, I see a few lingering RCS and
$FreeBSD$ tags.  For example, lib/msun/amd64/s_scalbnl.S
contains

/* RCSID("$NetBSD: s_scalbnf.S,v 1.4 1999/01/02 05:15:40 kristerw Exp $") */

Should this be cleaned up or ws intentional left in the 
source code?


-- 
Steve

Re: Proposal: Disable compression of newsyslog by default

[Steve Kargl]

On Sat, Dec 23, 2023 at 11:13:23AM -0800, Xin Li wrote:
> 
> I appreciate your perspective on this issue. However, I believe there are
> additional benefits to modifying the newsyslog code (which is already done
> in commit 906748d208d3, by the way) beyond what can be achieved by simply
> adjusting the defaults in newsyslog.conf.

Why ask for others opinions if you're simply going to commit
the change?  It seems the commit (23 Dec 2023 06:53:06 UTC)
occurred before the initial post in the discussion here
(23 Dec 2023 07:18:23 UTC).

-- 
Steve

Re: panic in cypto code

[Steve Kargl]

On Thu, Oct 05, 2023 at 03:11:02PM -0700, Steve Kargl wrote:
> 
> I'll ping you off list when it's available.
> 

Well, this is interesting.  I cannot upload the files to 
a location from which I can then put them up on freefall. :(

% scp -P1234 kernel.debug 10.95.76.21:
kernel.debug0%  255KB 255.0KB/s   04:01 
ETAclient_loop: send disconnect: Broken pipe
lost connection
% scp -P1234 vmcore.2  10.95.76.21:
vmcore.20%  255KB 254.9KB/s   49:46 
ETAclient_loop: send disconnect: Broken pipe
lost connection

Looks like if_ovpn,ko is autoloaded.
%  kldstat | grep ovpn
231 0x82042000 6650 if_ovpn.ko

Don't know what if_ovpn.ko does in hijacking tun0, but dying after
255kB is likely not correct.

-- 
Steve

Re: panic in cypto code

[Steve Kargl]

On Thu, Oct 05, 2023 at 11:33:46PM +0200, Kristof Provost wrote:
> On 5 Oct 2023, at 19:34, Steve Kargl wrote:
> > On Thu, Oct 05, 2023 at 06:05:37PM +0200, Kristof Provost wrote:
> >>
> >> On 5 Oct 2023, at 17:36, Steve Kargl wrote:
> >>> In case anyone else is using openvpn.
> >>>

(dump removed to keep this brief)

> >>>
> >> Do you have a bit more information about what happened here?
> >> As in: can you reproduce this, or do you have any idea what
> >> was going on to trigger this?  Did anything change in your
> >> setup (i.e. is if_ovpn use new, or did you update either kernel
> >> or userspace or ?
> >
> > I updated the system on the date displayed by 'uname -a'.
> > This included both base system and all installed ports;
> > including openvpn.  I normally leave the system running Xorg,
> > and I would find the system in a "locked-up" blank-screen
> > saver state.  I assumed I was having a Xorg/drm-kmod problem,
> > so I shut Xorg down last night.  The above panic was waiting
> > for me this morning.  The panic happens every night.
> >
> > Note , I don't use if_ovpn.  This a client over a tun0 device
> > through wlan0.
> >
> The backtrace contradicts you, but DCO is relatively transparent,
> so it’s quite possible you didn’t notice. It defaults to being
> enabled, and ought to just work.

Certainly, possible as I only quickly reviewed the dump.
The kernel is a custom kernel.  I don't recall adding a 
"device opvn" line.  Perhaps, starting openvpn autoloads a 
kernel module.  I'll need to check when I get home.

> >>
> >> Do you have the full core dump to poke at?
> >>
> >
> > Yes, I do, but it's on a home system.  I can put it up on
> > my kargl@freefall later tonight (in 10-ish hours).  I'll
> > include the dmesg.boot so you have some idea about the
> > hardware.
> >
> That’d be very helpful, thanks.
> 

I'll ping you off list when it's available.

-- 
Steve

Re: panic in cypto code

[Steve Kargl]

On Thu, Oct 05, 2023 at 06:05:37PM +0200, Kristof Provost wrote:
> Hi Steve,
> 
> On 5 Oct 2023, at 17:36, Steve Kargl wrote:
> > In case anyone else is using openvpn.
> >
> > %  pkg info openvpn
> > openvpn-2.6.6
> > Name   : openvpn
> > Version: 2.6.6
> > Installed on   : Tue Sep 19 08:48:55 2023 PDT
> > Origin : security/openvpn
> > Architecture   : FreeBSD:15:amd64
> >
> > % uname -a
> > FreeBSD hotrats 15.0-CURRENT #1 main-n265325-9c30461dd25b:
> > Thu Sep 14 08:09:18 PDT 2023 kargl@hotrats:$PATH/HOTRATS amd64
> >
> >
> > Fatal double fault
> > rip 0x8099b408 rsp 0xfe000e1cc000 rbp 0xfe000e1cc010
> > rax 0x53749f62934c5349 rdx 0x53749f62934c5349 rbx 0xfe000e1cc200
> > rcx 0x57bf32fec3cbde70 rsi 0x32e8db2f0591c5da rdi 0x832f0fb1e6d07eb0
> > r8 0 r9 0 r10 0
> > r11 0x60 r12 0x5af7589946bd13d9 r13 0xbeddd6a808e1dd54
> > r14 0xcdf12bbf2708189c r15 0xeb262ae8536a7adf rflags 0x10246
> > cs 0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b
> > fsbase 0x1c02e381d120 gsbase 0x81a1 kgsbase 0
> > cpuid = 0; apic id = 00
> > panic: double fault
> > cpuid = 0
> > time = 1696512769
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> > 0x812b3060
> > vpanic() at vpanic+0x132/frame 0x812b3190
> > panic() at panic+0x43/frame 0x812b31f0
> > dblfault_handler() at dblfault_handler+0x1ce/frame 0x812b32b0
> > Xdblfault() at Xdblfault+0xd7/frame 0x812b32b0
> > --- trap 0x17, rip = 0x8099b408, rsp = 0xfe000e1cc000, rbp = 
> > 0xfe000e1cc010 ---
> > gfmultword4() at gfmultword4+0x8/frame 0xfe000e1cc010
> > gf128_mul4b() at gf128_mul4b+0x63/frame 0xfe000e1cc050
> > AES_GMAC_Update() at AES_GMAC_Update+0x73/frame 0xfe000e1cc0b0
> > swcr_gcm() at swcr_gcm+0x660/frame 0xfe000e1cc830
> > swcr_process() at swcr_process+0x1a/frame 0xfe000e1cc850
> > crypto_dispatch() at crypto_dispatch+0x42/frame 0xfe000e1cc870
> > ovpn_transmit_to_peer() at ovpn_transmit_to_peer+0x54e/frame 
> > 0xfe000e1cc8d0
> > ovpn_output() at ovpn_output+0x2a2/frame 0xfe000e1cc950
> > ip_output() at ip_output+0x11f6/frame 0xfe000e1cca40
> > ovpn_encap() at ovpn_encap+0x3e7/frame 0xfe000e1ccac0
> >
> > #13 0x80ae08ce in dblfault_handler (frame=)
> > at /usr/src/sys/amd64/amd64/trap.c:1012
> > #14 
> > #15 0x8099b408 in gfmultword4 (worda=3668422891496654298,
> > wordb=9452791399630012080, wordc=6013606648173318985,
> > wordd=6322828471639465584, x=..., tbl=0xfe000e1cc200)
> > at /usr/src/sys/opencrypto/gfmult.c:174
> > #16 0x8099b5d3 in gf128_mul4b (r=...,
> > v=v@entry=0xf800076b9a64 
> > "\3156}\373\312w\254iBnD\001ܹ˾\353&*\350Sjz߃/\017\261\346\320~\260Z\367X\231F\275\023\331St\237b\223LSI\276\335֨\b\341\335TW\2772\376\303\313\336pN\265\023\352\2054\002\a/˦9R\321\366p\f\352\204P\360\270\371\250\\\aE?7s\377\253\217b\262%\214\317m",
> > tbl=tbl@entry=0xfe000e1cc200) at 
> > /usr/src/sys/opencrypto/gfmult.c:268
> > #17 0x8099ab13 in AES_GMAC_Update (ctx=0xfe000e1cc200,
> > vdata=, len=144) at /usr/src/sys/opencrypto/gmac.c:94
> > #18 0x80998ae0 in swcr_gcm (ses=0xf8020376a048,
> > crp=0xf80023386c08) at /usr/src/sys/opencrypto/cryptosoft.c:505
> > #19 0x80997c4a in swcr_process (dev=,
> > crp=0xf80023386c08, hint=)
> > at /usr/src/sys/opencrypto/cryptosoft.c:1680
> >
> Do you have a bit more information about what happened here?
> As in: can you reproduce this, or do you have any idea what
> was going on to trigger this?  Did anything change in your
> setup (i.e. is if_ovpn use new, or did you update either kernel
> or userspace or ?

I updated the system on the date displayed by 'uname -a'.
This included both base system and all installed ports;
including openvpn.  I normally leave the system running Xorg,
and I would find the system in a "locked-up" blank-screen
saver state.  I assumed I was having a Xorg/drm-kmod problem,
so I shut Xorg down last night.  The above panic was waiting
for me this morning.  The panic happens every night.

Note , I don't use if_ovpn.  This a client over a tun0 device
through wlan0.

> 
> Do you have the full core dump to poke at?
> 

Yes, I do, but it's on a home system.  I can put it up on
my kargl@freefall later tonight (in 10-ish hours).  I'll
include the dmesg.boot so you have some idea about the 
hardware.

> It might be a bug in the crypto code, but it could also
> be a bug in the if_ovpn code, so I’d like to work out
> what caused this.

Thanks for the quick reply.

-- 
Steve

panic in cypto code

[Steve Kargl]

In case anyone else is using openvpn.

%  pkg info openvpn
openvpn-2.6.6
Name   : openvpn
Version: 2.6.6
Installed on   : Tue Sep 19 08:48:55 2023 PDT
Origin : security/openvpn
Architecture   : FreeBSD:15:amd64

% uname -a
FreeBSD hotrats 15.0-CURRENT #1 main-n265325-9c30461dd25b:
Thu Sep 14 08:09:18 PDT 2023 kargl@hotrats:$PATH/HOTRATS amd64


Fatal double fault
rip 0x8099b408 rsp 0xfe000e1cc000 rbp 0xfe000e1cc010
rax 0x53749f62934c5349 rdx 0x53749f62934c5349 rbx 0xfe000e1cc200
rcx 0x57bf32fec3cbde70 rsi 0x32e8db2f0591c5da rdi 0x832f0fb1e6d07eb0
r8 0 r9 0 r10 0
r11 0x60 r12 0x5af7589946bd13d9 r13 0xbeddd6a808e1dd54
r14 0xcdf12bbf2708189c r15 0xeb262ae8536a7adf rflags 0x10246
cs 0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b
fsbase 0x1c02e381d120 gsbase 0x81a1 kgsbase 0
cpuid = 0; apic id = 00
panic: double fault
cpuid = 0
time = 1696512769
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x812b3060
vpanic() at vpanic+0x132/frame 0x812b3190
panic() at panic+0x43/frame 0x812b31f0
dblfault_handler() at dblfault_handler+0x1ce/frame 0x812b32b0
Xdblfault() at Xdblfault+0xd7/frame 0x812b32b0
--- trap 0x17, rip = 0x8099b408, rsp = 0xfe000e1cc000, rbp = 
0xfe000e1cc010 ---
gfmultword4() at gfmultword4+0x8/frame 0xfe000e1cc010
gf128_mul4b() at gf128_mul4b+0x63/frame 0xfe000e1cc050
AES_GMAC_Update() at AES_GMAC_Update+0x73/frame 0xfe000e1cc0b0
swcr_gcm() at swcr_gcm+0x660/frame 0xfe000e1cc830
swcr_process() at swcr_process+0x1a/frame 0xfe000e1cc850
crypto_dispatch() at crypto_dispatch+0x42/frame 0xfe000e1cc870
ovpn_transmit_to_peer() at ovpn_transmit_to_peer+0x54e/frame 0xfe000e1cc8d0
ovpn_output() at ovpn_output+0x2a2/frame 0xfe000e1cc950
ip_output() at ip_output+0x11f6/frame 0xfe000e1cca40
ovpn_encap() at ovpn_encap+0x3e7/frame 0xfe000e1ccac0

#13 0x80ae08ce in dblfault_handler (frame=)
at /usr/src/sys/amd64/amd64/trap.c:1012
#14 
#15 0x8099b408 in gfmultword4 (worda=3668422891496654298, 
wordb=9452791399630012080, wordc=6013606648173318985, 
wordd=6322828471639465584, x=..., tbl=0xfe000e1cc200)
at /usr/src/sys/opencrypto/gfmult.c:174
#16 0x8099b5d3 in gf128_mul4b (r=..., 
v=v@entry=0xf800076b9a64 
"\3156}\373\312w\254iBnD\001ܹ˾\353&*\350Sjz߃/\017\261\346\320~\260Z\367X\231F\275\023\331St\237b\223LSI\276\335֨\b\341\335TW\2772\376\303\313\336pN\265\023\352\2054\002\a/˦9R\321\366p\f\352\204P\360\270\371\250\\\aE?7s\377\253\217b\262%\214\317m",
 
tbl=tbl@entry=0xfe000e1cc200) at /usr/src/sys/opencrypto/gfmult.c:268
#17 0x8099ab13 in AES_GMAC_Update (ctx=0xfe000e1cc200, 
vdata=, len=144) at /usr/src/sys/opencrypto/gmac.c:94
#18 0x80998ae0 in swcr_gcm (ses=0xf8020376a048, 
crp=0xf80023386c08) at /usr/src/sys/opencrypto/cryptosoft.c:505
#19 0x80997c4a in swcr_process (dev=, 
crp=0xf80023386c08, hint=)
at /usr/src/sys/opencrypto/cryptosoft.c:1680

-- 
Steve

Re: 14.0-CURRENT boots fine but keyboard does not work

[Steve Kargl]

On Tue, Sep 05, 2023 at 01:29:34PM -0600, Warner Losh wrote:
> +/*
> + * Some Chromebooks don't confirm to the google comment above so do the

s/confirm/conform  ?


> + * Chromebook workaround for all <= 2018 coreboot systems that have a
> + * 'blank' version.  At least once Acer "Peppy" chromebook has this
> issue,

s/once/one  ?

-- 
Steve

Re: core dump in ld during buildworld

[Steve Kargl]

On Sun, Feb 19, 2023 at 07:21:54PM +0100, Dimitry Andric wrote:
> On 19 Feb 2023, at 06:15, Steve Kargl  
> wrote:
> > 
> > On Sat, Feb 18, 2023 at 04:57:45PM -0800, Steve Kargl wrote:
> >>> 
> >>> At that point it is still using the system compiler and linker, and it
> >>> seems that the latter is lld. Do you know which version it is?
> >>> 
> >> 
> >> Good question.  Unfortunate ident(1) is useless in a git world.
> >> 
> >> % ll /usr/bin/ld.lld
> >> -r-xr-xr-x  1 root  wheel  - 41754432 Jan 15 12:03 /usr/bin/ld.lld
> >> 
> >> This was built from source from Jan 15 2023.
> >> 
> >> % /usr/bin/ld.lld --version
> >> LLD 14.0.5 (FreeBSD llvmorg-14.0.5-0-gc12386ae247c-144) (compatible 
> >> with GNU linkers)
> >> 
> > 
> > So, is there some way to rebild only ld.lld and install a new loader?
> > 
> > % cd /usr/src/usr.bin/clang/lld
> > % make depend
> > llvm-tblgen -gen-opt-parser-defs -I 
> > /usr/src/contrib/llvm-project/llvm/include -d Options.inc.d  -o Options.inc 
> > /usr/src/contrib/llvm-project/lld/ELF/Options.td
> > make: exec(llvm-tblgen) failed (No such file or directory)
> > *** Error code 1
> > 
> > How to I fix this?
> 
> Assuming llvm-tblgen has already been built (it's a bootstrap-tool),
> and you have a regular setup, it should be in:
> 
> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/clang/llvm-tblgen/llvm-tblgen
> 
> You could try setting LLVM_TBLGEN to that path, then first build libllvm
> just to be sure, then usr.bin/clang/lld:
> 
> export 
> LLVM_TBLGEN=/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/clang/llvm-tblgen/llvm-tblgen
> make -C /usr/src/lib/clang/libllvm
> make -C /usr/src/usr.bin/clang/lld
> 
> If that works, you can run make install from usr.bin/clang/lld.
> 

Thanks for the hints.  The above got me past the segfault 
in ld.ldd.  I now have an error about libdwarf.a being 
truncated and extended beyond some limit while building
nm.  I'm simply do 'make -k buildworld' now to see if 
anything is running south.


-- 
Steve

Re: core dump in ld during buildworld

[Steve Kargl]

On Sat, Feb 18, 2023 at 04:57:45PM -0800, Steve Kargl wrote:
> > 
> > At that point it is still using the system compiler and linker, and it
> > seems that the latter is lld. Do you know which version it is?
> > 
> 
> Good question.  Unfortunate ident(1) is useless in a git world.
> 
> % ll /usr/bin/ld.lld
> -r-xr-xr-x  1 root  wheel  - 41754432 Jan 15 12:03 /usr/bin/ld.lld
> 
> This was built from source from Jan 15 2023. 
> 
> % /usr/bin/ld.lld --version
> LLD 14.0.5 (FreeBSD llvmorg-14.0.5-0-gc12386ae247c-144) (compatible with 
> GNU linkers)
>  

So, is there some way to rebild only ld.lld and install a new loader?

% cd /usr/src/usr.bin/clang/lld
% make depend
llvm-tblgen -gen-opt-parser-defs -I /usr/src/contrib/llvm-project/llvm/include 
-d Options.inc.d  -o Options.inc 
/usr/src/contrib/llvm-project/lld/ELF/Options.td
make: exec(llvm-tblgen) failed (No such file or directory)
*** Error code 1

How to I fix this?

-- 
Steve

Re: core dump in ld during buildworld

[Steve Kargl]

On Sun, Feb 19, 2023 at 01:50:07AM +0100, Dimitry Andric wrote:
> On 19 Feb 2023, at 01:33, Steve Kargl  
> wrote:
> > 
> > During biuldworld,
> > 
> > ==> usr.bin/nm (obj,all,install)
> > cc -O2 -pipe -g -fno-common -I/usr/src/contrib/elftoolchain/libelftc 
> > -I/usr/src/contrib/elftoolchain/common -std=gnu99 -Wno-format-zero-length 
> > -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
> > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
> > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
> > -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition 
> > -Wno-pointer-sign -Wdate-time -Wmissing-variable-declarations 
> > -Wthread-safety -Wno-empty-body -Wno-string-plus-int 
> > -Wno-unused-const-variable -Wno-error=unused-but-set-variable 
> > -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include  
> > -Wl,-zrelro -static   -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib -o 
> > nm nm.o  -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf -ldwarf 
> > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf 
> > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz 
> > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc -lelftc_pie 
> > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf  -legacy
> > PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include 
> > the crash backtrace.
> > Stack dump:
> > 0.  Program arguments: /usr/bin/ld --eh-frame-hdr -Bstatic -o nm 
> > /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbeginT.o 
> > -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib 
> > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf 
> > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf 
> > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz 
> > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc 
> > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -L/usr/lib -zrelro 
> > nm.o -ldwarf -lelf -lz -lelftc_pie -lelf -legacy -lgcc -lgcc_eh -lc -lgcc 
> > -lgcc_eh /usr/lib/crtend.o /usr/lib/crtn.o
> > #0 0x0164f1c1 (/usr/bin/ld+0x164f1c1)
> > #1 0x0164d4a5 (/usr/bin/ld+0x164d4a5)
> > #2 0x0164f8e0 (/usr/bin/ld+0x164f8e0)
> > #3 0x000825243a60 (/lib/libthr.so.3+0x19a60)
> > #4 0x00082524301f (/lib/libthr.so.3+0x1901f)
> > #5 0x0008231e48a3 ([vdso]+0x2d3)
> > #6 0x00cf4830 (/usr/bin/ld+0xcf4830)
> > #7 0x00cf7b89 (/usr/bin/ld+0xcf7b89)
> > #8 0x00cf55a3 (/usr/bin/ld+0xcf55a3)
> > #9 0x00cf5217 (/usr/bin/ld+0xcf5217)
> > #10 0x00dabe23 (/usr/bin/ld+0xdabe23)
> > #11 0x00da7754 (/usr/bin/ld+0xda7754)
> > #12 0x00cf4ec5 (/usr/bin/ld+0xcf4ec5)
> > #13 0x00cc6e83 (/usr/bin/ld+0xcc6e83)
> > #14 0x00cbe4bc (/usr/bin/ld+0xcbe4bc)
> > #15 0x00cbccda (/usr/bin/ld+0xcbccda)
> > cc: error: unable to execute command: Segmentation fault (core dumped)
> > cc: error: linker command failed due to signal (use -v to see invocation)
> > *** Error code 254
> > 
> > Stop.
> > make[3]: stopped in /usr/src/usr.bin/nm
> > *** Error code 1
> > 
> > % find /usr/obj/ -name \*.core
> > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/nm/ld.lld.core
> > %  uname -a
> > FreeBSD hotrats 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
> > main-n260094-906c312bbf74: Fri Feb  3 21:28:39 PST 2023 
> > kargl@hotrats:/usr/obj/usr/src/amd64.amd64/sys/HOTRATS amd64
> > 
> > Is the wrong ld being called?  The failing command shows /usr/bin/ld.
> > Should this be  /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld?
> 
> It looks like this happens during the early stages, most likely
> cross-tools? (As it appears to be building usr.bin/nm under obj-tools.)
> 
> At that point it is still using the system compiler and linker, and it
> seems that the latter is lld. Do you know which version it is?
> 

Good question.  Unfortunate ident(1) is useless in a git world.

% ll /usr/bin/ld.lld
-r-xr-xr-x  1 root  wheel  - 41754432 Jan 15 12:03 /usr/bin/ld.lld

This was built from source from Jan 15 2023. 

% /usr/bin/ld.lld --version
LLD 14.0.5 (FreeBSD llvmorg-14.0.5-0-gc12386ae247c-144) (compatible with 
GNU linkers)
 

-- 
Steve

core dump in ld during buildworld

[Steve Kargl]

During biuldworld, 

==> usr.bin/nm (obj,all,install)
cc -O2 -pipe -g -fno-common -I/usr/src/contrib/elftoolchain/libelftc 
-I/usr/src/contrib/elftoolchain/common -std=gnu99 -Wno-format-zero-length 
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign 
-Wdate-time -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-variable -Qunused-arguments 
-I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include  -Wl,-zrelro -static   
-L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib -o nm nm.o  
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf -ldwarf 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc -lelftc_pie 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf  -legacy
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the 
crash backtrace.
Stack dump:
0.  Program arguments: /usr/bin/ld --eh-frame-hdr -Bstatic -o nm 
/usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbeginT.o 
-L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -L/usr/lib -zrelro nm.o 
-ldwarf -lelf -lz -lelftc_pie -lelf -legacy -lgcc -lgcc_eh -lc -lgcc -lgcc_eh 
/usr/lib/crtend.o /usr/lib/crtn.o
 #0 0x0164f1c1 (/usr/bin/ld+0x164f1c1)
 #1 0x0164d4a5 (/usr/bin/ld+0x164d4a5)
 #2 0x0164f8e0 (/usr/bin/ld+0x164f8e0)
 #3 0x000825243a60 (/lib/libthr.so.3+0x19a60)
 #4 0x00082524301f (/lib/libthr.so.3+0x1901f)
 #5 0x0008231e48a3 ([vdso]+0x2d3)
 #6 0x00cf4830 (/usr/bin/ld+0xcf4830)
 #7 0x00cf7b89 (/usr/bin/ld+0xcf7b89)
 #8 0x00cf55a3 (/usr/bin/ld+0xcf55a3)
 #9 0x00cf5217 (/usr/bin/ld+0xcf5217)
#10 0x00dabe23 (/usr/bin/ld+0xdabe23)
#11 0x00da7754 (/usr/bin/ld+0xda7754)
#12 0x00cf4ec5 (/usr/bin/ld+0xcf4ec5)
#13 0x00cc6e83 (/usr/bin/ld+0xcc6e83)
#14 0x00cbe4bc (/usr/bin/ld+0xcbe4bc)
#15 0x00cbccda (/usr/bin/ld+0xcbccda)
cc: error: unable to execute command: Segmentation fault (core dumped)
cc: error: linker command failed due to signal (use -v to see invocation)
*** Error code 254

Stop.
make[3]: stopped in /usr/src/usr.bin/nm
*** Error code 1

% find /usr/obj/ -name \*.core
/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/nm/ld.lld.core
%  uname -a
FreeBSD hotrats 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n260094-906c312bbf74: 
Fri Feb  3 21:28:39 PST 2023 
kargl@hotrats:/usr/obj/usr/src/amd64.amd64/sys/HOTRATS amd64

Is the wrong ld being called?  The failing command shows /usr/bin/ld.
Should this be  /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld?

-- 
Steve

Re: buildworld failure

[Steve Kargl]

On Sat, Feb 18, 2023 at 12:33:11AM -0800, Jeffrey Bouquet wrote:
> Building /usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.c
> Building /usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.o
> sys_bitcount.c:1:10: fatal error: 'sys/bitcount.h' file not found
> #include 
>  ^~~~
> 1 error generated.
> *** Error code 1
> 
> Stop.
> make[3]: stopped in /usr/src/tools/build/test-includes
> .ERROR_TARGET='sys_bitcount.o'
> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.o.meta'
> .MAKE.LEVEL='3'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
> _ERROR_CMD='/usr/local/bin/clang14  -O2 -pipe -fno-common   -g -gz=zlib 
> -std=gnu99 -Wno-format-zero-length -nobuiltininc -idirafter 
> /usr/local/llvm14/lib/clang/14.0.6/include -fstack-protector-strong 
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
> -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign 
> -Wdate-time -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
> -Wno-string-plus-int -Wno-unused-const-variable 
> -Wno-error=unused-but-set-variable  -Qunused-arguments-c sys_bitcount.c 
> -o sys_bitcount.o; ;'
> .CURDIR='/usr/src/tools/build/test-includes'
> .MAKE='make'
> .OBJDIR='/usr/obj/usr/src/amd64.amd64/tools/build/test-includes'
> .TARGETS='test-includes'
> DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp'
> LD_LIBRARY_PATH=''
> MACHINE='amd64'
> MACHINE_ARCH='amd64'
> MAKEOBJDIRPREFIX=''
> MAKESYSPATH='/usr/src/share/mk'
> MAKE_VERSION='20220208'
> PATH='/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin'
> SRCTOP='/usr/src'
> OBJTOP='/usr/obj/usr/src/amd64.amd64
> .
> 
> Anyone see/know anything causing this error? 
> Also, the buildworld command most likely to build the most amd64 components 
> from scratch? 

I'm seeing a different buildworld problem.

===> usr.bin/nm (obj,all,install)   

cc -O2 -pipe -fno-common -I/usr/src/contrib/elftoolchain/libelftc 
-I/usr/src/contrib/elftoolchain/common -std=gnu99 -Wno-format-zero-length 
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition 
-Wno-pointer-sign -Wdate-time -Wmissing-variable-declarations -Wthrea
d-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-variable -Qunused-arguments 
-I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include  -Wl,-zrelro -static  
 -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib -o nm nm.o  
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf -ldwarf 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf -L/usr
/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc -lelftc_pie 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf  -legacy  
  
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the 
crash backtrace.
Stack dump:
0.  Program arguments: /usr/bin/ld --eh-frame-hdr -Bstatic -o nm 
/usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbeginT.o 
-L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc 
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -L/usr/lib -zrelro nm.o 
-ldwarf -lelf -lz -lelftc_pie -lelf -legacy -lgcc -lgcc_eh -lc -lgcc -lgcc_eh 
/usr/lib/crtend.o /usr/lib/crtn.o
 #0 0x0164f1c1 (/usr/bin/ld+0x164f1c1)
 #1 0x0164d4a5 (/usr/bin/ld+0x164d4a5)
 #2 0x0164f8e0 (/usr/bin/ld+0x164f8e0)
 #3 0x000827446a60 (/lib/libthr.so.3+0x19a60)
 #4 0x00082744601f (/lib/libthr.so.3+0x1901f)
 #5 0x00082362e8a3 ([vdso]+0x2d3)

Re: The dma mess

[Steve Kargl]

On Mon, Dec 05, 2022 at 05:30:50PM +0100, Baptiste Daroussin wrote:
> On Mon, Dec 05, 2022 at 07:42:29AM -0800, Steve Kargl wrote:
> > If one has not seen Mike Karel's email, here's the URL.
> > 
> > https://lists.freebsd.org/archives/dev-commits-src-main/2022-December/011300.html
> > 
> > The upshot is 
> > 
> > 1) No entry in src/UPDATING about dma replacing sendmail, and thereby
> >breaking a function system on upgrade.
> 
> Fixed
> > 
> > 2) Having sendmail_enable="YES" in /etc/rc.conf no longer works
> >after an upgrade, because dma replaces /etc/mail/mailer.conf.
> >sendmail appears to start, but exits immediately.  One needs
> >to go through a serious of git commits to find out about this
> >easter egg.
> 
> It does again.
> > 
> > 3) It seems that now one must also add
> > 
> >sendmail_submit_enable="YES"
> >sendmail_msp_queue_enable="YES"
> >sendmail_outbound_enable="YES"
> > 
> >to rc.conf to recover a functioning sendmail.
> 
> Not anymore.
> 

Thanks.  

-- 
Steve

The dma mess

[Steve Kargl]

If one has not seen Mike Karel's email, here's the URL.

https://lists.freebsd.org/archives/dev-commits-src-main/2022-December/011300.html

The upshot is 

1) No entry in src/UPDATING about dma replacing sendmail, and thereby
   breaking a function system on upgrade.

2) Having sendmail_enable="YES" in /etc/rc.conf no longer works
   after an upgrade, because dma replaces /etc/mail/mailer.conf.
   sendmail appears to start, but exits immediately.  One needs
   to go through a serious of git commits to find out about this
   easter egg.

3) It seems that now one must also add

   sendmail_submit_enable="YES"
   sendmail_msp_queue_enable="YES"
   sendmail_outbound_enable="YES"

   to rc.conf to recover a functioning sendmail.

When I upgrade the system next month, will dma remove the 
ability to use sendmail without unfixing whatever damage
it does?

POLA?

-- 
Steve

Re: CA's TLS Certificate Bundle in base = BAD

[Steve Kargl]

On Sat, Dec 03, 2022 at 08:26:16PM -0500, grarpamp wrote:
> there or for some other reason. That's all bad news :( But can be fixed :)
> 

It looks like the FreeBSD mailing list software
stripped your attachment with your patch.  Can
you try sending it again with the patch in-line?

-- 
steve

Re: A panic a day

[Steve Kargl]

On Thu, Sep 22, 2022 at 03:00:53PM -0400, Mark Johnston wrote:
> 
> I think this untested patch will address the panics.  The bug was there
> for a long time but some recent restructuring added an assertion which
> caught it.
> 
> diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
> index 9d48aa746f6d..484864b66c1c 100644
> --- a/sys/kern/sched_4bsd.c
> +++ b/sys/kern/sched_4bsd.c
> @@ -1282,9 +1282,10 @@ kick_other_cpu(int pri, int cpuid)
>   }
>  #endif /* defined(IPI_PREEMPTION) && defined(PREEMPTION) */
>  
> - ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
> - ipi_cpu(cpuid, IPI_AST);
> - return;
> + if (pcpu->pc_curthread->td_lock == &sched_lock) {
> + ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
> + ipi_cpu(cpuid, IPI_AST);
> + }
>  }
>  #endif /* SMP */
>  
> @@ -1397,7 +1398,7 @@ sched_add(struct thread *td, int flags)
>  
>   cpuid = PCPU_GET(cpuid);
>   if (single_cpu && cpu != cpuid) {
> - kick_other_cpu(td->td_priority, cpu);
> + kick_other_cpu(td->td_priority, cpu);
>   } else {
>   if (!single_cpu) {
>   tidlemsk = idle_cpus_mask;

Mark,

My system has been running a fairly heavy load with this
patch for the last 20 or so hours without any incidences.
In fact, the system feels snappier.  Thanks for the quick
response with a patch.

-- 
Steve

Re: A panic a day

[Steve Kargl]

On Thu, Sep 22, 2022 at 09:07:08PM +0200, Mateusz Guzik wrote:
> On 9/22/22, Steve Kargl  wrote:
> > On Thu, Sep 22, 2022 at 03:00:53PM -0400, Mark Johnston wrote:
> >> On Thu, Sep 22, 2022 at 11:31:40AM -0700, Steve Kargl wrote:
> >> > All,
> >> >
> >> > I updated my kernel/world/all ports on Sept 19 2022.
> >> > Since then, I have had daily panics and hard lock-up
> >> > (no panic, keyboard, mouse, network, ...).  The one
> >> > panic I did witness sent text scolling off the screen.
> >> > There is no dump, or at least, I haven't figured out
> >> > a way to get a dump.
> >> >
> >> > Using ports/graphics/tesseract and then hand editing
> >> > the OCR result, the last visible portions is
> >> >
> >> >
> >
> > (panic messages removed).
> >
> >> It looks like you use the 4BSD scheduler?  I think there's a bug in
> >> kick_other_cpu() in that it doesn't make sure that the remote CPU's
> >> curthread lock is held when modifying thread state.  Because 4BSD has a
> >> global scheduler lock, this is often true in practice, but doesn't have
> >> to be.
> >
> > Yes, I use 4BSD.  ULE has very poor performance for HPC type work with
> > OpenMPI.
> >
> 
> Is there an easy way to set it up for testing purposes?
> 

I reported this years ago.  One instance is here

https://lists.freebsd.org/pipermail/freebsd-hackers/2008-October/026375.html

and, I've tested ULE a few times since.

A HPC program, compiled with openmpi, can spawn multiple images.
The gist of the problem is that under ULE, if one gets in an
over-subscribed situation (e.g., N+1 images and only N cpus),
then ULE's cpu affinity will place two images on 1 cpu.  Those
images ping-pong.  The other N-1 images run happily.  An image
that completes its task will then wait on the ping-pong match
before getting its next quantum of work.  Under 4BSD, the N+1
images simply run on the N cpus where each gets a cpu slice. 

Note, you don't need an openmpi program to get this situation.
Simply use a numerical intensive code that takes 5 or so minutes
to complete.  Start N+1 jobs.  You'll get 2 jobs completing for
1 CPU.   

-- 
Steve

Re: A panic a day

[Steve Kargl]

On Thu, Sep 22, 2022 at 03:00:53PM -0400, Mark Johnston wrote:
> On Thu, Sep 22, 2022 at 11:31:40AM -0700, Steve Kargl wrote:
> > All,
> > 
> > I updated my kernel/world/all ports on Sept 19 2022.
> > Since then, I have had daily panics and hard lock-up
> > (no panic, keyboard, mouse, network, ...).  The one
> > panic I did witness sent text scolling off the screen.
> > There is no dump, or at least, I haven't figured out
> > a way to get a dump.
> > 
> > Using ports/graphics/tesseract and then hand editing 
> > the OCR result, the last visible portions is
> > 
> > 

(panic messages removed).

> It looks like you use the 4BSD scheduler?  I think there's a bug in
> kick_other_cpu() in that it doesn't make sure that the remote CPU's
> curthread lock is held when modifying thread state.  Because 4BSD has a
> global scheduler lock, this is often true in practice, but doesn't have
> to be.

Yes, I use 4BSD.  ULE has very poor performance for HPC type work with
OpenMPI.  

> I think this untested patch will address the panics.  The bug was there
> for a long time but some recent restructuring added an assertion which
> caught it.

I'll give it a try, and report back.  Thanks!

-- 
steve

> diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
> index 9d48aa746f6d..484864b66c1c 100644
> --- a/sys/kern/sched_4bsd.c
> +++ b/sys/kern/sched_4bsd.c
> @@ -1282,9 +1282,10 @@ kick_other_cpu(int pri, int cpuid)
>   }
>  #endif /* defined(IPI_PREEMPTION) && defined(PREEMPTION) */
>  
> - ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
> - ipi_cpu(cpuid, IPI_AST);
> - return;
> + if (pcpu->pc_curthread->td_lock == &sched_lock) {
> + ast_sched_locked(pcpu->pc_curthread, TDA_SCHED);
> + ipi_cpu(cpuid, IPI_AST);
> + }
>  }
>  #endif /* SMP */
>  
> @@ -1397,7 +1398,7 @@ sched_add(struct thread *td, int flags)
>  
>   cpuid = PCPU_GET(cpuid);
>   if (single_cpu && cpu != cpuid) {
> - kick_other_cpu(td->td_priority, cpu);
> + kick_other_cpu(td->td_priority, cpu);
>   } else {
>   if (!single_cpu) {
>   tidlemsk = idle_cpus_mask;

-- 
Steve

A panic a day

[Steve Kargl]

All,

I updated my kernel/world/all ports on Sept 19 2022.
Since then, I have had daily panics and hard lock-up
(no panic, keyboard, mouse, network, ...).  The one
panic I did witness sent text scolling off the screen.
There is no dump, or at least, I haven't figured out
a way to get a dump.

Using ports/graphics/tesseract and then hand editing 
the OCR result, the last visible portions is


panic() at panic+0x43/frame 0xfe00daf65550
__mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc6/frame 0xfe00daf655e0
sched_add() at sched_add+0x98/frame 0xfe00daf656a0
setrunnable() at setrunnable+0x73/frame 0xfe00daf656d0
wakeup_any() at wakeup_any+0x1f/frame 0xfe00daf656f0
taskqueue_enqueue_locked() at taskqueue_enqueue_locked+0x13e/frame 
0xfe00daf65720
taskqueue_enqueue_timeout_sbt() at taskqueue_enqueue_timeout_sbt+0xe5/frame 
0xfe00daf65770
resettodr() at resettodr+0x7a/frame 0xfe00daf657b0
kern_reboot() at kern_reboot+0x2ae/frame 0xfe00daf657f0
vpanic() at vpanic+0x1be/frame 0xfe00daf65840
panic() at panic+0x43/frame 0xfe00daf658a0
__mtx_lock_spin_flags() at __mix_lock_spin_flags+0xc6/frame 0xfe00daf65ab0
sched_add() at sched_add+0x98/frame 0xfe00daf65990
setrunnable() at setrunnable+0x73/frame 0xfe008daf659c0
wakeup_any() at wakeup_any+0x1f/frame 0xfe00daf659e0
taskqueue_enqueue_locked() at taskqueue_enqueue_locked+0x13e/frame 
0xfe00daf65a11
drm_crtc_helper_set_config() at drm_crtc_helper_set_config+0x971/frame 
0xfe00daf65abl
radeon_crtc_set_config() at radeon_crtc_set_config+0x22/frame 0xfe00daf65ad0
__drm_mode_set_config_internal() at __drm_mode_set_config_internal+0xdd/frame 
0xfe00daf65b10
drm_client_modeset_commit_locked() at 
drm_client_modeset_commit_locked+0x160/frame 0xfe00daf65b50
drm_client_modeset_commit() at drm_client_modeset_commit+0x21/frame 
0xfe00daf65b70
drm_fb_helper_restore_fbdev_mode_unlocked() at 
drm_fb_helper_restore_fbdev_mode_unlocked+0x81/frame 
vt_kms_postswitch() at vt_kms_postswitch+0x166/frame 0xfe00daf65bd0
vt_window_switch() at vt_window_switch+0x119/frame 0xfe00daf65c1d
vtterm_cngrab() at vtterm_cngrab+0x4f/frame 0xfe00daf65c30
cngrab() at cngrab+0x26/frame 0xfe00daf65ca0
vpanic() at vpanic+0xf0/frame 0xfe00daf65ca0
panic() at panic+0x43/frame 0xfe00daf65d00
__mtx_assert() at __mtx_assert+0x9d/frame 0xfe00daf65d10
ast_sched_locked() at ast_sched_locked+0x29/frame 0xfe00daf65d30
sched_add() at sched_add+0x4c5/frame 0xfe00daf65df0
sched_switch() at sched_switch+0x9f/frame 0xfe00daf65e20
mi_switch() at mi_switch+0x14b/frame 0xfe00daf65e40
sched_bind() at sched_bind+0x73/frame 0xfe00daf65e60
pcpu_cache_drain_safe() at pcpu_cache_drain_safe+0x25a/frame 0xfe00daf65e90
uma_reclaim_domain() at uma_reclain_domain+0x279/frame Buf e00dafohech
uma_reclaim_worker() at uma_reclaim_worker+0x35/frame 0xfe00daf65ef0
fork_exit() at fork_exit+0x80/frame 0xfe00daf65f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe00daf65f30
--- trap 0, rip = 0, rop = 0, rbp = 0 ---

panic: mtx_lock_spin: recursed on non-recursive mutex sleepq chain @ 
/usr/src/sys/kern/subr_sleepqueue.c:267

cpuid = 7
time = 1663634259
KDB: stack backtrace:
db_trace_self_wrapper() at 

-- 
Steve

Re: buildkernel is broken

[Steve Kargl]

On Thu, Jul 07, 2022 at 07:59:29PM +0200, Kristof Provost wrote:
> On 7 Jul 2022, at 19:00, Steve Kargl wrote:
>
> > The fix in
> > 37f604b49d4a seems rather questionable especially given
> > that there is no comment about why the macro is expanded
> > to a zero-trip loop.
> > 
> I’m not sure how I could have been much more clear than this:
> 
> VNET_FOREACH() is a LIST_FOREACH if VIMAGE is set, but empty if it's
> not. This means that users of the macro couldn't use 'continue' or
> 'break' as one would expect of a loop.

Comments belong in the code.

/* Kludge to prevent non-vimage kernels from choking to death. */
#define VNET_FOREACH(arg)   for (int _vn = 0; _vn == 0; _vn++)


-- 
Steve

Re: buildkernel is broken

[Steve Kargl]

On Thu, Jul 07, 2022 at 10:37:40AM -0600, Warner Losh wrote:
> On Thu, Jul 7, 2022 at 10:37 AM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
> 
> > Thanks, but
> >
> > root[216] git cherry-pick -n 37f604b49d4a
> > fatal: bad revision '37f604b49d4a'
> > root[217] pwd
> > /usr/src
> 
> 
> git fetch maybe?
> 

A cursory google search suggests that 'git fetch' 
works on repositories not single files.

I did look at the diff associated with 37f604b49d4a.
I am surprised that the commit that broke buildkernel
for me was allowed to be committed.  The fix in
37f604b49d4a seems rather questionable especially given
that there is no comment about why the macro is expanded
to a zero-trip loop.

Thanks for the help.  I'll just do a 'git pull'
and start over with a buildworld.
 
-- 
Steve

Re: buildkernel is broken

[Steve Kargl]

Thanks, but

root[216] git cherry-pick -n 37f604b49d4a
fatal: bad revision '37f604b49d4a'
root[217] pwd
/usr/src

-- 
steve

On Thu, Jul 07, 2022 at 11:24:47AM -0400, Ryan Stone wrote:
> You could "git cherry-pick -n 37f604b49d4a; git restore --unstaged
> sys/net/vnet.h" to apply the fix to your local tree without committing
> it or leaving it staged for commit.
> 
> On Thu, Jul 7, 2022 at 10:50 AM Steve Kargl
>  wrote:
> >
> > On Thu, Jul 07, 2022 at 10:38:43AM -0400, Ryan Stone wrote:
> > > Okay, update your tree and it should be fixed then.
> >
> > Is it possible to pull just that fix?  I spent part of
> > yesterday building world, and contrary to popular belief,
> > not all hardware contain a 32-core uber-fast ryzen cpu.
> >
> > Can people please test their simple changes prior to
> > committing?
> >
> > --
> > Steve

-- 
Steve

Re: buildkernel is broken

[Steve Kargl]

On Thu, Jul 07, 2022 at 10:38:43AM -0400, Ryan Stone wrote:
> Okay, update your tree and it should be fixed then.

Is it possible to pull just that fix?  I spent part of
yesterday building world, and contrary to popular belief,
not all hardware contain a 32-core uber-fast ryzen cpu.

Can people please test their simple changes prior to
committing?

-- 
Steve

Re: buildkernel is broken

[Steve Kargl]

Yes, I do.

Deleting the line allows to code to compile.

-- 
steve

On Thu, Jul 07, 2022 at 08:24:47AM -0400, Ryan Stone wrote:
> Do you have VNET disabled in your kernel config?  I believe that this
> was fixed by 37f604b49d4a.
> 
> On Thu, Jul 7, 2022 at 1:07 AM Steve Kargl
>  wrote:
> >
> > -std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_input.c
> > --- modules-all ---
> > /usr/src/sys/netpfil/ipfw/ip_dn_io.c:674:4: error: 'continue' statement not 
> > in loop statement
> > continue;
> > ^
> > 1 error generated.
> > *** [ip_dn_io.o] Error code 1
> >
> > make[4]: stopped in /usr/src/sys/modules/dummynet
> > 1 error
> > *** [modules-all] Error code 6
> >
> > make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/SPEW
> > 1 error
> >
> > make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/SPEW
> > 5.75 real20.45 user 2.30 sys
> >
> > make[1]: stopped in /usr/src
> >
> >
> > Please fix.
> >
> > --
> > Steve
> >

-- 
Steve

buildkernel is broken

[Steve Kargl]

-std=iso9899:1999 -Werror /usr/src/sys/netinet/tcp_input.c
--- modules-all ---
/usr/src/sys/netpfil/ipfw/ip_dn_io.c:674:4: error: 'continue' statement not in 
loop statement
continue;
^
1 error generated.
*** [ip_dn_io.o] Error code 1

make[4]: stopped in /usr/src/sys/modules/dummynet
1 error
*** [modules-all] Error code 6

make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/SPEW
1 error

make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/SPEW
5.75 real20.45 user 2.30 sys

make[1]: stopped in /usr/src


Please fix.

-- 
Steve

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Wed, May 04, 2022 at 01:22:57PM -0700, John Baldwin wrote:
> On 5/4/22 12:53 PM, Steve Kargl wrote:
> > On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote:
> > 
> > I don't know the entire FreeBSD ecosystem.  Do people
> > use FreeBSD on embedded systems (e.g., nanobsd) where
> > libthr may be stripped out?  Thus, --enable-threads=no
> > is needed.
> 
> If they do, they are also using a constrained userland and
> probably are not shipping a GCC binary either.  However, it's
> not clear to me what --enable-threads means.
> 
> Does this enable -pthread as an option?  If so, that should
> definitely just always be on.  It's still an option users have
> to opt into via a command line flag and doesn't prevent
> building non-threaded programs.
> 
> If it's enabling use of threads at runtime within GCC itself,
> I'd say that also should probably just be allowed to be on.
> 
> I can't really imagine what else it might mean (and I doubt
> it means the latter).
> 

AFAICT, it controls whether -lpthread is automatically added to
the command line.  In the case of -pg, it is -lpthread_p.
The relevant lines are

#ifdef FBSD_NO_THREADS
#define FBSD_LIB_SPEC " \
  %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \
is built with the --enable-threads configure-time option.}  \
  %{!shared:\
%{!pg: -lc} \
%{pg:  -lc_p}   \
  }"
#else
#define FBSD_LIB_SPEC " \
  %{!shared:\
%{!pg: %{pthread:-lpthread} -lc}\
%{pg:  %{pthread:-lpthread_p} -lc_p}\
  } \
  %{shared: \
%{pthread:-lpthread} -lc\
  }"
#endif

Ed is wondering if one can get rid of FBSD_NO_THREADS. With the
pending removal of WITH_PROFILE, the above reduces to

#define FBSD_LIB_SPEC " \
  %{!shared:\
%{pthread:-lpthread} -lc\
  } \
  %{shared: \
%{pthread:-lpthread} -lc\
  }"

If one can do the above, then freebsd-nthr.h is no longer needed
and can be deleted and config.gcc's handling of --enable-threads
can be updated/removed.

-- 
Steve

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Wed, May 04, 2022 at 11:12:55AM -0700, John Baldwin wrote:
> On 5/2/22 10:37 AM, Steve Kargl wrote:
> > On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote:
> > > On Sun, 1 May 2022 at 11:54, Steve Kargl
> > >  wrote:
> > > > 
> > > > diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h
> > > > index 594487829b5..1e8ab2e1827 100644
> > > > --- a/gcc/config/freebsd-spec.h
> > > > +++ b/gcc/config/freebsd-spec.h
> > > > @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME 
> > > > respectively.  If not, see
> > > >  (similar to the default, except no -lg, and no -p).  */
> > > > 
> > > >   #ifdef FBSD_NO_THREADS
> > > 
> > > I wonder if we can simplify things now, and remove this
> > > `FBSD_NO_THREADS` case. I didn't see anything similar in other GCC
> > > targets I looked at.
> > 
> > That I don't know.  FBSD_NO_THREADS is defined in freebsd-nthr.h.
> > In fact, it's the only thing in that header (except copyright
> > broilerplate).  freebsd-nthr.h only appears in config.gcc and
> > seems to only get added to the build if someone runs configure
> > with --enable-threads=no.  Looking at my last config.log for
> > gcc trunk, I see "Thread model: posix", which appears to be
> > the default case or if someone does --enable-threads=yes or
> > --enable-threads=posix.  So, I suppose it comes down to
> > two questions: (1) is libpthread.* available on all supported
> > targets and versions? (2) does anyone build gcc without
> > threads support?
> 
> libpthread is available on all supported architectures on all
> supported versions.  libthr has been the default threading library
> since 7.0 and the only supported library since 8.0.  In GDB I just
> assume libthr style threads, and I think GCC can safely do the
> same.
> 

I don't know the entire FreeBSD ecosystem.  Do people
use FreeBSD on embedded systems (e.g., nanobsd) where
libthr may be stripped out?  Thus, --enable-threads=no
is needed.

gcc/config/freebsd-nthr.h was committed on May 22, 2001.
There have been no changes to the file other than cosmetic
ones (e.g., updating copyright notice).

gcc/config/freebsd-spec.h has had a number of changes.
Someone with a better understanding of the spec file
will need to clean that up.

-- 
Steve

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Mon, May 02, 2022 at 10:37:00AM -0700, Steve Kargl wrote:
> On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote:
> > On Sun, 1 May 2022 at 11:54, Steve Kargl
> >  wrote:
> > >
> > > diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h
> > > index 594487829b5..1e8ab2e1827 100644
> > > --- a/gcc/config/freebsd-spec.h
> > > +++ b/gcc/config/freebsd-spec.h
> > > @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME 
> > > respectively.  If not, see
> > > (similar to the default, except no -lg, and no -p).  */
> > >
> > >  #ifdef FBSD_NO_THREADS
> > 
> > I wonder if we can simplify things now, and remove this
> > `FBSD_NO_THREADS` case. I didn't see anything similar in other GCC
> > targets I looked at.
> 
> That I don't know.  FBSD_NO_THREADS is defined in freebsd-nthr.h.
> In fact, it's the only thing in that header (except copyright
> broilerplate).  freebsd-nthr.h only appears in config.gcc and
> seems to only get added to the build if someone runs configure
> with --enable-threads=no.  Looking at my last config.log for
> gcc trunk, I see "Thread model: posix", which appears to be
> the default case or if someone does --enable-threads=yes or
> --enable-threads=posix.  So, I suppose it comes down to 
> two questions: (1) is libpthread.* available on all supported
> targets and versions? (2) does anyone build gcc without 
> threads support?
> 

Well, I built and executed gcc testsuite with and without
threads enabled.  Either a few new test failures in the
disable case may unilaterally assume threads are available,
or these are in fact issues (with a rarely used configure
option).



config 1
../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran,lto \
  --enable-bootstrap --disable-nls --enable-checking --disable-multilib

config 2
../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran,lto \
  --enable-bootstrap --disable-nls --enable-checking --disable-multilib \
  --enable-threads=no --disable-threads

=== g++ Summary ===

config 1  config 2
# of expected passes225442 225348
# of unexpected failures675724
# of expected failures  2071   2071
# of unresolved testcases   11 47
# of unsupported tests  10342  10342

=== gcc Summary ===

# of expected passes175562 175401
# of unexpected failures1046   1116
# of unexpected successes   20 20
# of expected failures  1459   1459
# of unresolved testcases   10 92
# of unsupported tests  3260   3260

=== gfortran Summary ===

# of expected passes66124  66046
# of unexpected failures6  84
# of expected failures  272272
# of unresolved testcases   2  2
# of unsupported tests  100100

-- 
Steve

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Mon, May 02, 2022 at 12:32:25PM -0400, Ed Maste wrote:
> On Sun, 1 May 2022 at 11:54, Steve Kargl
>  wrote:
> >
> > diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h
> > index 594487829b5..1e8ab2e1827 100644
> > --- a/gcc/config/freebsd-spec.h
> > +++ b/gcc/config/freebsd-spec.h
> > @@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME 
> > respectively.  If not, see
> > (similar to the default, except no -lg, and no -p).  */
> >
> >  #ifdef FBSD_NO_THREADS
> 
> I wonder if we can simplify things now, and remove this
> `FBSD_NO_THREADS` case. I didn't see anything similar in other GCC
> targets I looked at.

That I don't know.  FBSD_NO_THREADS is defined in freebsd-nthr.h.
In fact, it's the only thing in that header (except copyright
broilerplate).  freebsd-nthr.h only appears in config.gcc and
seems to only get added to the build if someone runs configure
with --enable-threads=no.  Looking at my last config.log for
gcc trunk, I see "Thread model: posix", which appears to be
the default case or if someone does --enable-threads=yes or
--enable-threads=posix.  So, I suppose it comes down to 
two questions: (1) is libpthread.* available on all supported
targets and versions? (2) does anyone build gcc without 
threads support?

-- 
Steve

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Sat, Apr 30, 2022 at 04:07:48PM -0400, Ed Maste wrote:
> On Sat, 30 Apr 2022 at 11:34, Steve Kargl
>  wrote:
> >
> > On Sat, Apr 30, 2022 at 09:39:32AM -0400, Ed Maste wrote:
> > > On Fri, 29 Apr 2022 at 01:58, Steve Kargl
> > >  wrote:
> > > >
> > > > If one looks at src.conf(5), one finds
> > > >
> > > >WITH_PROFILE
> > > >  Build profiled libraries for use with gprof(8).  This option is
> > > >  deprecated and is not present in FreeBSD 14.
> > > >
> > > > I assume that the *_p.a libraries will no longer be built and
> > > > installed on FreeBSD 14 and later.  Is this correct?
> > >
> > > FreeBSD 14 is not yet released, of course, but that is indeed the
> > > intent. PR256874 reports that a GCC patch (to stop linking against
> > > _p.a) is in the works but unfortunately has not had an update for some
> > > time.
> >
> > I see.  It only took me 2+ years to get
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125
> >
> > committed to the GCC repository.  Good luck with
> > getting your patch upstream.
> 
> Heh, thanks.
> 
> I have just now changed the WITH_PROFILE description to state "a
> future version of FreeBSD" since it may well not happen for FreeBSD
> 14.
> 
> We could also just install libc_p.a as a symlink to libc.a (and same
> for the other _p.a archives).

This works for me, but there is one addition place dealing with -pg
in freebsd-spec.h


diff --git a/gcc/config/freebsd-spec.h b/gcc/config/freebsd-spec.h
index 594487829b5..1e8ab2e1827 100644
--- a/gcc/config/freebsd-spec.h
+++ b/gcc/config/freebsd-spec.h
@@ -93,14 +93,22 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
(similar to the default, except no -lg, and no -p).  */
 
 #ifdef FBSD_NO_THREADS
+#if FBSD_MAJOR < 14
 #define FBSD_LIB_SPEC "
\
-  %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \
+ %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \
 is built with the --enable-threads configure-time option.} \
   %{!shared:   \
 %{!pg: -lc}
\
 %{pg:  -lc_p}  \
   }"
 #else
+#define FBSD_LIB_SPEC "
\
+ %{pthread: %eThe -pthread option is only supported on FreeBSD when gcc \
+is built with the --enable-threads configure-time option.} \
+  }"
+#endif
+#else
+#if FBSD_MAJOR < 14
 #define FBSD_LIB_SPEC "
\
   %{!shared:   \
 %{!pg: %{pthread:-lpthread} -lc}   \
@@ -109,6 +117,15 @@ is built with the --enable-threads configure-time option.} 
\
   %{shared:\
 %{pthread:-lpthread} -lc   \
   }"
+#else
+#define FBSD_LIB_SPEC "
\
+  %{!shared:   \
+%{pthread:-lpthread} -lc   \
+  }\
+  %{shared:\
+%{pthread:-lpthread} -lc   \
+  }"
+#endif
 #endif
 
 /* To make matters interesting, we can't actually use __FreeBSD_version
-- 
Steve

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Sat, Apr 30, 2022 at 09:39:32AM -0400, Ed Maste wrote:
> On Fri, 29 Apr 2022 at 01:58, Steve Kargl
>  wrote:
> >
> > If one looks at src.conf(5), one finds
> >
> >WITH_PROFILE
> >  Build profiled libraries for use with gprof(8).  This option is
> >  deprecated and is not present in FreeBSD 14.
> >
> > I assume that the *_p.a libraries will no longer be built and
> > installed on FreeBSD 14 and later.  Is this correct?
> 
> FreeBSD 14 is not yet released, of course, but that is indeed the
> intent. PR256874 reports that a GCC patch (to stop linking against
> _p.a) is in the works but unfortunately has not had an update for some
> time.

I see.  It only took me 2+ years to get

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125

committed to the GCC repository.  Good luck with
getting your patch upstream.

-- 
Steve

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Fri, Apr 29, 2022 at 02:54:17PM -0700, Mark Millard wrote:
> On 2022-Apr-29, at 13:12, Steve Kargl  
> wrote:
> 
> > The evenual absence of libc_p.a and libm_p.a will break GCC's
> > -pg option in GCC.  One will then need to know how to change the
> > GCC source or install symlinks for to point *_p.a a the *.a libs.
> > 
> 
> src/tree/tools/build/mk/OptionalObsoleteFiles.inc shows the
> following that does include those 2 files as ones considered
> obsolete (i.e., to be removed) by WITHOUT_PROFILE:
> 

(snip)

> 
> I expect that this is part of the mechanism that will
> ultimately remove those then-out-of-date files from
> systems when WITH_PROFILE is no longer supported.
> 
> Metion was made of "[a] similar change is still needed
> for GCC" --but I've no clue of the details or status.
> 

Therein lies the problem.  None of the people pushing the
removal of WITH[OUT]_PROFILE have submitted a patch to 
fix GCC.  Anyone installing a lang/gccXXX port will be
met with errors when using -pg.  

-- 
Steve

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Fri, Apr 29, 2022 at 12:51:12PM -0700, Mark Millard wrote:
> On 2022-Apr-29, at 12:38, Mark Millard  wrote:
> 
> > https://cgit.freebsd.org/src/commit/?id=175841285e289edebb6603da39f02549521ce950
> > says the following (later), but first I quote the part tbat dirves the
> > interpretation:
> > 
> > QUOTE
> > Clang's -pg support and mcount() remain, so building with -pg can still
> > be used on code that the user builds; we just do not provide prebuilt
> > libraries compiled with -pg.
> > END QUOTE
> > 
> > No WITH_PROFILE options means no "prebuilt libraries compiled with -pg".
> > 
> > 
> > The overall notice was:
> > 
> > author  Ed Maste2021-06-27 17:21:26 +
> > committer   Ed Maste2021-06-28 15:36:59 +
> > commit  175841285e289edebb6603da39f02549521ce950 (patch)
> > tree9c2d3b05546961457bb18faeebd2302a25559b49
> > parent  243b95978debac3db06df6d26ca9f8d84f6cbd83 (diff)
> > downloadsrc-175841285e289edebb6603da39f02549521ce950.tar.gz
> > src-175841285e289edebb6603da39f02549521ce950.zip
> > 
> > Add deprecation notice for WITH_PROFILE option
> > 
> > As discussed on freebsd-current [1] and freebsd-arch [2] and review
> > D30833, FreeBSD 14 will ship without the _p.a libraries built with -pg.
> > Both upstream and base system (in commit b762974cf4b9) Clang have been
> > modified to remove the special case for linking against these libraries.
> > 
> > Clang's -pg support and mcount() remain, so building with -pg can still
> > be used on code that the user builds; we just do not provide prebuilt
> > libraries compiled with -pg.  A similar change is still needed for GCC.
> > 
> > [1]  
> > https://lists.freebsd.org/pipermail/freebsd-current/2020-January/075105.html
> > 
> > [2] 
> > https://lists.freebsd.org/archives/freebsd-arch/2021-June/16.html
> > 
> > 
> > MFC after:  1 week
> > Sponsored by:   The FreeBSD Foundation
> > END QUOTE
> > 
> 
> I probably should have been explicit: the actual removal of WITH_PROFILE
> has not happened yet. So testing attempts to use it are not yet expected
> to have the new behavior yet.
> 

The evenual absence of libc_p.a and libm_p.a will break GCC's
-pg option in GCC.  One will then need to know how to change the
GCC source or install symlinks for to point *_p.a a the *.a libs.

-- 
Steve

Re: Profiled libraries on freebsd-current

[Steve Kargl]

On Thu, Apr 28, 2022 at 10:56:48PM -0700, Steve Kargl wrote:
> If one looks at src.conf(5), one finds
> 
>WITH_PROFILE
>  Build profiled libraries for use with gprof(8).  This option is
>  deprecated and is not present in FreeBSD 14.
> 
> I assume that the *_p.a libraries will no longer be built and
> installed on FreeBSD 14 and later.  Is this correct?
> 

Empirical evidence suggests that src.conf(5) manpage is
incorrect.  Adding WITH_PROFILE to /etc/src.conf, 

cd msun
cd make clean && make
ls /usr/obj/usr/src/amd64.amd64/lib/msun/libm*
/usr/obj/usr/src/amd64.amd64/lib/msun/libm.a
/usr/obj/usr/src/amd64.amd64/lib/msun/libm.so@
/usr/obj/usr/src/amd64.amd64/lib/msun/libm.so.5*
/usr/obj/usr/src/amd64.amd64/lib/msun/libm_p.a

so libm_p.a is built.  I haven't tried to install it.

git blame share/man/man5/src.conf.5
...
f94360971e64 (Ed Maste 2021-06-28 17:30:48 -0400 1392)
f94360971e64 (Ed Maste  2021-06-28 17:30:48 -0400 1393)

git log -r f94360971e64
commit f94360971e649fa684ef3b7e72839b59c7242bdb
Author: Ed Maste 
Date:   Mon Jun 28 17:30:48 2021 -0400

Clarify notice for profiled libraries in FreeBSD 14

Well, that certainly clarifies the situation.

Could someone please fix src.conf(5)?

-- 
Steve

Profiled libraries on freebsd-current

[Steve Kargl]

If one looks at src.conf(5), one finds

   WITH_PROFILE
 Build profiled libraries for use with gprof(8).  This option is
 deprecated and is not present in FreeBSD 14.

I assume that the *_p.a libraries will no longer be built and
installed on FreeBSD 14 and later.  Is this correct?

-- 
Steve

Re: Daily black screen of death

[Steve Kargl]

On Thu, Apr 21, 2022 at 09:44:04AM +0200, Emmanuel Vadot wrote:
> 
>  Hello Steve,
> 
> On Tue, 19 Apr 2022 11:32:32 -0700
> Steve Kargl  wrote:
> 
> > FYI,
> > 
> > I'm experiencing an almost daily black screen of death panic.
> > Kernel, world, drm-current-kmod, and gpu-firmware-kmod were
> > all rebuilt and installed at the same time.  Uname shows
> > 
> > FreeBSD 14.0-CURRENT #0 main-n254360-eb9d205fa69: Tue Apr 5 13:49:47 PDT 
> > 2022
> > 
> > So, April 5th sources.
> > 
> > The panic results in a keyboard lock and no dump.  The system
> > does not have a serial console.  Only recourse is a hard rest.
> > 
> > Hand transcribed from photo
> > 
> > _sleep() at _sleep+0x38a/frame 0xfe012b7c0680
> > buf_daemon_shutdown() at buf_daemon_shutdown+0x6b/frame 0xfe012b7c06a0
> > kern_reboot() at kern_reboot+0x2ae/frame 0xfe012b7c06e0
> > vpanic() at vpanic+0x1ee/frame 0xfe012b7c0730
> > panic() at panic+0x43/frame 0xfe012b7c0790
> > 
> > Above repeats 100s of time scrolling off the screen with ever
> > increasing frame pointer.
> > 
> > Final message,
> > 
> > mi_switch() at mi_switch+0x18e/frame 0xfe012b7c14b0
> > __mtx_lock_sleep() at __mtx_lock_sleep+0x173/frame 0xfe012b7c1510
> > __mtx_lock_flags() at __mtx_lock_flags+0xc0/frame 0xfe012b7c1550
> > linux_wake_up() at linux_wake_up+0x38/frame 0xfe012b7c15a0
> > radeon_fence_is_signaled() at radeon_fence_is_signaled+0x99/frame 
> > 0xfe012b7c15f0
> > dma_resv_add_shared_fence() at dma_resv_add_shared_fence+0x99/frame 
> > 0xfe012b7c1640
> > ttm_eu_fence_buffer_objects() at ttm_eu_fence_buffer_objects+0x79/frame 
> > 0xfe012b7c1680
> > radeon_cs_parser_fini() at radeon_cs_parser_fini+0x53/frame 
> > 0xfe012b7c16b0
> > radeaon_cs_ioctl() at radeaon_cs_ioctl+0x75e/frame 0xfe012b7c1b30
> > drm_ioctl_kernel() at drm_ioctl_kernel+0xc7/frame 0xfe012b7c1b80
> > drm_ioctl() at drm_ioctl+0x2c3/frame 0xfe012b7c1c70
> > linux_file_ioctl() at linux_file_ioctl+0x309/frame 0xfe012b7c1cd0
> > kern_ioctl() at kern_ioctl+0x1dc/frame 0xfe012b7c1d40
> > sys_ioctl() at sys_ioctl+0x121/frame 0xfe012b7c1e10
> > amd64_syscall() at amd64_syscall+0x108/frame 0xfe012b7c1f30
> > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe012b7c1f30
> > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x36a096c34ea, rsp = 
> > 0x3fa11e623eb8, \
> > rbp = 0x3fa11e623ee0 ---
> > panic: _sleep: curthread not running
> > cpuid = 4
> > time = 1650389478
> > KDB: stack backtrace:
> > 
> > One common trigger appears to be the use of firefox-99.0,2 from
> > the ports collection.  
> > 
> > -- 
> > Steve
> > 
> 
>  What version of drm are you using ?
>  Since when do you experience this ?
>  drm as not changed much for a long time now except adapting a few
> files for new linuxkpi addition.
> 

drm-current-kmod-5.4.144.g20220223
gpu-firmware-kmod-g20210330

I upgraded a Jan 2022 kernel+world+drm+gpu 2 to 3 weeks ago.
The Jan 2022 system just worked.  I've had the problem since
the upgrade.  I've also rebuild firefox, libdrm, the X-server,
and X11 libraries.  Still see the panic.

As the panic messages scroll off the screen, I'm not sure the
above last bit is the actual cause or simply a side effect.

Some additional info from a dmesg after the reboot.


WARNING: / was not properly dismounted
[drm] radeon kernel modesetting enabled.
drmn0:  on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
[drm] initializing kernel modesetting (CAICOS 0x1002:0x6779 0x1092:0x6450 0x00).
[drm ERROR :radeon_atombios_init] Unable to find PCI I/O BAR; using MMIO for 
ATOM IIO
ATOM BIOS: C26401
drmn0: VRAM: 1024M 0x - 0x3FFF (1024M used)
drmn0: GTT: 1024M 0x4000 - 0x7FFF
[drm] Detected VRAM RAM=1024M, BAR=256M
[drm] RAM width 64bits DDR
[TTM] Zone  kernel: Available graphics memory: 8359708 KiB
[TTM] Zone   dma32: Available graphics memory: 2097152 KiB
[TTM] Initializing pool allocator
[drm] radeon: 1024M of VRAM memory ready
[drm] radeon: 1024M of GTT memory ready.
[drm] Loading CAICOS Microcode
drmn0: successfully loaded firmware image 'radeon/CAICOS_pfp.bin'
drmn0: successfully loaded firmware image 'radeon/CAICOS_me.bin'
drmn0: successfully loaded firmware image 'radeon/BTC_rlc.bin'
drmn0: successfully loaded firmware image 'radeon/CAICOS_mc.bin'
drmn0: successfully loaded firmware image 'radeon/CAICOS_smc.bi

Daily black screen of death

[Steve Kargl]

FYI,

I'm experiencing an almost daily black screen of death panic.
Kernel, world, drm-current-kmod, and gpu-firmware-kmod were
all rebuilt and installed at the same time.  Uname shows

FreeBSD 14.0-CURRENT #0 main-n254360-eb9d205fa69: Tue Apr 5 13:49:47 PDT 2022

So, April 5th sources.

The panic results in a keyboard lock and no dump.  The system
does not have a serial console.  Only recourse is a hard rest.

Hand transcribed from photo

_sleep() at _sleep+0x38a/frame 0xfe012b7c0680
buf_daemon_shutdown() at buf_daemon_shutdown+0x6b/frame 0xfe012b7c06a0
kern_reboot() at kern_reboot+0x2ae/frame 0xfe012b7c06e0
vpanic() at vpanic+0x1ee/frame 0xfe012b7c0730
panic() at panic+0x43/frame 0xfe012b7c0790

Above repeats 100s of time scrolling off the screen with ever
increasing frame pointer.

Final message,

mi_switch() at mi_switch+0x18e/frame 0xfe012b7c14b0
__mtx_lock_sleep() at __mtx_lock_sleep+0x173/frame 0xfe012b7c1510
__mtx_lock_flags() at __mtx_lock_flags+0xc0/frame 0xfe012b7c1550
linux_wake_up() at linux_wake_up+0x38/frame 0xfe012b7c15a0
radeon_fence_is_signaled() at radeon_fence_is_signaled+0x99/frame 
0xfe012b7c15f0
dma_resv_add_shared_fence() at dma_resv_add_shared_fence+0x99/frame 
0xfe012b7c1640
ttm_eu_fence_buffer_objects() at ttm_eu_fence_buffer_objects+0x79/frame 
0xfe012b7c1680
radeon_cs_parser_fini() at radeon_cs_parser_fini+0x53/frame 0xfe012b7c16b0
radeaon_cs_ioctl() at radeaon_cs_ioctl+0x75e/frame 0xfe012b7c1b30
drm_ioctl_kernel() at drm_ioctl_kernel+0xc7/frame 0xfe012b7c1b80
drm_ioctl() at drm_ioctl+0x2c3/frame 0xfe012b7c1c70
linux_file_ioctl() at linux_file_ioctl+0x309/frame 0xfe012b7c1cd0
kern_ioctl() at kern_ioctl+0x1dc/frame 0xfe012b7c1d40
sys_ioctl() at sys_ioctl+0x121/frame 0xfe012b7c1e10
amd64_syscall() at amd64_syscall+0x108/frame 0xfe012b7c1f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe012b7c1f30
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x36a096c34ea, rsp = 
0x3fa11e623eb8, \
rbp = 0x3fa11e623ee0 ---
panic: _sleep: curthread not running
cpuid = 4
time = 1650389478
KDB: stack backtrace:

One common trigger appears to be the use of firefox-99.0,2 from
the ports collection.  

-- 
Steve

Re: What to do about tgammal?

[Steve Kargl]

On Tue, Dec 21, 2021 at 03:46:40PM +0100, Marc Fonvieille wrote:
> Le 20.12.2021 16:48, Steve Kargl a écrit :
> > On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote:
> > >
> > > I assume what Steve is talking about is the corresponding value in
> > > decimal of the number of ULP.
> > > 
> > 
> > Bad assumption.  Please read Goldberg's paper.  I am talking
> > about ULP in the underlying floating point format.
> >
> 
> Thanks, it's more clear now: it's the ULP value.
> Is your tlibm_libm program available for testing ?  If I find time I'd like to
> do some tests.
> 

Not at the moment.  tlibm only handles math functions with
a single real agrument [1].  I've been thinking about adding
the 2 argument functions such as atan2 and complex argument
function, but lack the time.  I also need to improve the man
page to decoment the default domain for each function and its
complete domain.

[1] acos, acosh, asin, asinh, atan, atanh, cbrt, cos, cosh, erf,
erfc, exp, exp2, expm1, j0, j1, lgamma, log, log10, log1p,
log2, sin, sinh, sqrt, tan, tanh, tgamma, y0, y1.
-- 
Steve

Re: What to do about tgammal?

[Steve Kargl]

On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote:
>
> I assume what Steve is talking about is the corresponding value in
> decimal of the number of ULP.
> 

Bad assumption.  Please read Goldberg's paper.  I am talking
about ULP in the underlying floating point format.

-- 
Steve

Re: What to do about tgammal?

[Steve Kargl]

On Sat, Dec 18, 2021 at 10:41:14AM +, Mark Murray wrote:
> 
> Hmm. I think my understanding of ULP is missing something?
> 
> I thought that ULP could not be greater than the mantissa size
> in bits?
> 
> I.e., I thought it represents average rounding error (compared with
> "perfect rounding"), not truncation error, as the above very large
> ULPs suggest.
> 

The definition of ULP differs according which expert you
choose to follow. :-)  For me (a non-expert), ULP is measured
in the system of the "accurate answer", which is assumed to
have many more bits of precision than the "approximate answer".
>From a very old das@ email and for long double I have 

/* From a das email:
 *
 *   ulps = err * (2**(LDBL_MANT_DIG - e)), where e = ilogb(accurate).
 *
 * I use:
 *
 *   mpfr_sub(err, accurate, approximate, RNDN);
 *   mpfr_abs(err, err, RNDN);
 *   mpfr_mul_2si(ulpx, err, -mpfr_get_exp(accurate) + LDBL_MANT_DIG, RNDN);
 *   ulp = mpfr_get_d(ulpx, RNDN);
 *   if (ulp  0.506 && mpfr_cmpabs(err, ldbl_minx)  0) {
 * print warning...;
 *   }
 */

Here, "err = |accurate - approximate|" is done in the precision
of the "accurate answer", and RNDN is round-to-nearest.  The
line 'mpfr_mul_2si(...)' is doing the scaling to manipulate the
exponent of the radix 2.

This is agreement with Goldberg.  IIRC, Jean-Michel Muller et al
have much more detailed discussion about error and ULPs in their
book "Handbook of Floating-Point Arithmetic".   

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

So, on ld80 and tgamma, I have 

% tlibm -l -x 8 -X 1755 -n 10 -P tgamma
Interval tested for tgammal: [8,1755]
   ulp <= 0.5: 90.207% 90207 |  90.207% 90207
0.5 <  ulp <  0.6:  7.085%  7085 |  97.292% 97292
0.6 <  ulp <  0.7:  2.383%  2383 |  99.675% 99675
0.7 <  ulp <  0.8:  0.314%   314 |  99.989% 99989
0.8 <  ulp <  0.9:  0.011%11 | 100.000%10
Max ulp: 0.853190 at 9.236118561185611856579e+02

The "ulp <= 0.5" line indicates the number of correctly
rounded case.  If the value of ULP exceeds 1, then you are
starting to lose more than 1 bit in the significant.  Consider
individual points.  Here's a correctly rounded case:

% tlibm -l -a 9.23611856118500 tgamma
   xu = LD80C(0x93c72441a44a57a9, 3,  9.2361185611849994e+00L),
libmu = LD80C(0x82f85b3fe4b36f9b,16,  6.70567128873706962722e+04L),
mpfru = LD80C(0x82f85b3fe4b36f9b,16,  6.70567128873706962722e+04L),
 ULP = 0.42318

Notice, ULP < 0.5 and the bits in libm and mpfr answer rounded to 
long double are all the same as is the decimal representation. Now
consider the max ULP case:

% tlibm -l -a  9.236118561185611856579e+02 tgamma
   xu = LD80C(0xe6e728a690c4fa87, 9,  9.23611856118561185658e+02L),
libmu = LD80C(0xba6bea661a7eda3c,  7762,  5.7294439856327202e+2336L),
mpfru = LD80C(0xba6bea661a7eda3d,  7762,  5.7294439856327245e+2336L),
 ULP = 0.85319

ULP is < 1, which is desireable.  The bits agree except for the
last place where we're off by 1, ie, 0xc vs 0xd.  The decimal
representation is of course off.

So, now on grimoirei without my patch, I have 

% ./tlibm_libm -l -a 1.59255925592559255925592559255925594e+01 tgamma
   x =  1.59255925592559255925592559255925594e+01L
libm =  1.06660136733166064453125e+12L
mpfr =  1.06660136733166211967839038834033459e+12L,
 ULP = 13932370826141802496.0

You have 16 correct decimal digits out of 36, which is the best
you can expect from mapping tgammal to tgamma.  ULP is significant
larger than 1.  The ulp is almost guaranteed to be larger than
2**(113-53).

Now with my patch and worse case for 1 x in [10:16]

% ./tlibm_lmath -l -a 1.59255925592559255925592559255925594e+01 tgamma
  x =  1.59255925592559255925592559255925594e+01L
libm =  1.06660136733166211967839038834033897e+12
mpfr =  1.06660136733166211967839038834033459e+12L,
 ULP = 41.40877

I don't print out the hex representation in ld128, but you see
the number of correct decimal digits is 33 digits compared to
36.

-- 
Steve

Re: What to do about tgammal?

[Steve Kargl]

On Tue, Dec 14, 2021 at 10:21:55PM +, Mark Murray wrote:
> On 14 Dec 2021, at 21:51, Steve Kargl  
> wrote:
> > Interval  max ULP  x at Max ULP
> > [6,1755.1]0.873414 at 1.480588145237629047468e+03
> > [1.0662,6]0.861508 at 1.999467927053585410537e+00
> > [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00
> > [-1.,-1.0001] 3.157770 at -1.246957268051453610329e+00
> > [-2.,-2.0001] 2.987659 at -2.220949465449893090070e+00
> > 
> > Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or
> 
> Extra diffs most welcome!
> 

Hi Mark,

Don't know if you noticed, but I borroewed a few cpu cycles
from grimoire.  My WIP is already better than the imprecise.c
kludge from theraven@.  I need to work out the details of 
computing logl(x) in extra precision or see if I can leverage
what Bruce did a few years ago.  Anywho, current results:

Interval tested for tgammal: [128,1755]
count: 100
  xm =  1.71195767195767195767195767195767183e+03L
libm =  7.79438030237108165017007606176403036e+4790L
mpfr =  7.79438030237108165017007606175285456e+4790L
 ULP = 14869.19517

Interval tested for tgammal: [16,128]
count: 100
  xm =  1.27687183687183687183687183687183690e+02L
libm =  6.61421998891483212224382625339007663e+212L
mpfr =  6.61421998891483212224382625338960267e+212L
 ULP = 731.00958

Interval tested for tgammal: [10,16]
count: 100
  xm =  1.54261654261654261654261654261654251e+01L
libm =  2.74203137295418912508367515208072654e+11L
mpfr =  2.74203137295418912508367515208073861e+11L
 ULP = 45.61161

Interval tested for tgammal: [1.2446e-60,10]
count: 100
  xm =  6.26200626138006138006138006138006065e-02L
libm =  1.54507103764516989381203274093299079e+01L
mpfr =  1.54507103764516989381203274093299091e+01L
 ULP = 0.76751




-- 
Steve

Re: What to do about tgammal?

[Steve Kargl]

On Tue, Dec 14, 2021 at 03:47:17PM -0700, Warner Losh wrote:
> On Tue, Dec 14, 2021 at 3:23 PM Mark Murray  wrote:
> 
> > On 14 Dec 2021, at 21:51, Steve Kargl 
> > wrote:
> > > Interval  max ULP  x at Max ULP
> > > [6,1755.1]0.873414 at 1.480588145237629047468e+03
> > > [1.0662,6]0.861508 at 1.999467927053585410537e+00
> > > [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00
> > > [-1.,-1.0001] 3.157770 at -1.246957268051453610329e+00
> > > [-2.,-2.0001] 2.987659 at -2.220949465449893090070e+00
> > >
> > > Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or
> >
> > Extra diffs most welcome!
> >
> 
> Those results have allayed my fears. Is 1e-17 sufficient to commit these
> changes, or do
> we need to work to get it down to 1e-19 for it to be acceptable?
> 

Well, egg-on-the-face.  I updated the sloppy limit to isolate
x = 0 from 0x1p-56 to use 0x1p-116 and forgot to update my test
scripts.  The code in tgammal in the interval [-iota:iota] is

if (x > iota)
RETURNI(smaller_gam(x));

if (x > -iota) {
if (x != 0)
u.a = 1 - tiny; /* raise inexact */
RETURNI(1 / x);
}

so tgammal(x) -> 1/x as x -> 0.


-- 
Steve

Re: What to do about tgammal?

[Steve Kargl]

On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote:
> 
> This is now visible for review at
> https://reviews.freebsd.org/D33444 
> 

I see imp lamented that that fact that he is not sufficiently
versed in the numerical methods used (neither am I!).  bde
use to be my go-to reviewer, but he's no longer with us.  To
allay fears, I've tested 5 million values distributed in the
intervals of the various approximations.  Here's the result

 Interval  max ULP  x at Max ULP
[6,1755.1]0.873414 at 1.480588145237629047468e+03
[1.0662,6]0.861508 at 1.999467927053585410537e+00
[1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00
[-1.,-1.0001] 3.157770 at -1.246957268051453610329e+00
[-2.,-2.0001] 2.987659 at -2.220949465449893090070e+00 

Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or
1.01e-20.

-- 
Steve

Re: What to do about tgammal?

[Steve Kargl]

On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote:
> 
> This is now visible for review at
> https://reviews.freebsd.org/D33444 
> 

Just looked at this again.  I cannot tell from the
diff whether you've 'git mv' src/imprecise.c to 
ld128/b_tgammal.c.  This is need to still get the
mapping of tgammal -> tgamma.

-- 
Steve

Re: What to do about tgammal?

[Steve Kargl]

On Tue, Dec 14, 2021 at 06:26:13PM +, Mark Murray wrote:
> 
> This is now visible for review at
> https://reviews.freebsd.org/D33444 
> 

Thanks!  I looks okay to me (but, of course, I wrote the patch ;-)

BTW, I'll probably take a shot at ld128 tgammal(x) this
weekend as I still have my account on your aarch64 system
for testing.

-- 
Steve

Re: What to do about tgammal?

[Steve Kargl]

On Sat, Dec 04, 2021 at 11:48:13PM +, Mark Murray wrote:
> 
> 
> > On 4 Dec 2021, at 18:53, Steve Kargl  
> > wrote:
> > 
> > 
> > So, is anyone interested in seeing a massive patch?
> 
> Me, please!
> 

So, I have the ld80 case working.  I'll open a PR if 
on does not exist.  The pr will contain

1) Diff for nonfunctional changes to code for tgamma(x).
This is a re-organization of the code so I could reverse
it.  Some cleanup of comments and documentations.  A
move towards style(9)

2) Advice on what to do about tgammal(x) on ld128 hardware.
   Essentially, need to do the git equivalent of 'svn mv
   imprecise.c ld128/b_tgammal.c.

3) Diff with the new code for ld80 tgamma.


Interval tested for tgammal: [6,1755.1]
500 calls, 2.056068 secs, 0.41121 usecs/call
   ulp <= 0.5: 90.233%   4511666 |  90.233%   4511666
0.5 <  ulp <  0.6:  7.061%353033 |  97.294%   4864699
0.6 <  ulp <  0.7:  2.393%119644 |  99.687%   4984343
0.7 <  ulp <  0.8:  0.300% 14981 |  99.986%   4999324
0.8 <  ulp <  0.9:  0.014%   676 | 100.000%   500
Max ulp: 0.873414 at 1.480588145237629047468e+03

Interval tested for tgammal: [1.0662,6]
500 calls, 0.748966 secs, 0.14979 usecs/call
   ulp <= 0.5: 96.355%   4817737 |  96.355%   4817737
0.5 <  ulp <  0.6:  3.291%164534 |  99.645%   4982271
0.6 <  ulp <  0.7:  0.328% 16403 |  99.973%   4998674
0.7 <  ulp <  0.8:  0.026%  1297 |  99.999%   471
0.8 <  ulp <  0.9:  0.001%29 | 100.000%   500
Max ulp: 0.861508 at 1.999467927053585410537e+00

Interval tested for tgammal: [1.01e-17,1.0661]
500 calls, 0.904246 secs, 0.18085 usecs/call
   ulp <= 0.5: 96.201%   4810043 |  96.201%   4810043
0.5 <  ulp <  0.6:  3.297%164875 |  99.498%   4974918
0.6 <  ulp <  0.7:  0.412% 20581 |  99.910%   4995499
0.7 <  ulp <  0.8:  0.082%  4108 |  99.992%   4999607
0.8 <  ulp <  0.9:  0.008%   389 | 100.000%   496
0.9 <  ulp <  1.0:  0.000% 4 | 100.000%   500
Max ulp: 0.938041 at 1.023286481537296307856e+00

Interval tested for tgammal: [-1.,-1.0001]
500 calls, 1.740820 secs, 0.34816 usecs/call
   ulp <= 0.5: 56.596%   2829776 |  56.596%   2829776
0.5 <  ulp <  0.6:  8.616%430793 |  65.211%   3260569
0.6 <  ulp <  0.7:  7.452%372621 |  72.664%   3633190
0.7 <  ulp <  0.8:  6.250%312511 |  78.914%   3945701
0.8 <  ulp <  0.9:  5.147%257372 |  84.061%   4203073
0.9 <  ulp <  1.0:  4.100%205010 |  88.162%   4408083
1.0 <  ulp <  1.5:  9.846%492324 |  98.008%   4900407
1.5 <  ulp <  2.0:  1.790% 89514 |  99.798%   4989921
2.0 <  ulp <  3.0:  0.201% 10074 | 100.000%   495
3.0 <  ulp <  0.0:  0.000% 5 | 100.000%   500

-- 
Steve

Re: What to do about tgammal?

[Steve Kargl]

On Sat, Dec 04, 2021 at 11:48:13PM +, Mark Murray wrote:
> 
> 
> > On 4 Dec 2021, at 18:53, Steve Kargl  
> > wrote:
> > 
> > 
> > So, is anyone interested in seeing a massive patch?
> 
> Me, please!
> 

It is ld80 only.  ld128 is still broken.  I'll clean things
up and create a diff over the next few days.  The patch
will disconnect imprecise.c from the build.  So, if you like
what you see and pursue committing the patch(es),
one pre-requisite will be to copy src/imprecise.c to 
ld128/b_tgammal.c.  In the good old day, one would use

% svn copy src/imprecise.c ld128/b_tgammal.c
% svn delete src/imprecise.c

or 

% svn move src/imprecise.c ld128/b_tgammal.c

Don't know (or care) how to do this in a git world.

-- 
Steve

Re: What to do about tgammal?

[Steve Kargl]

On Sat, Dec 04, 2021 at 08:40:56PM +0100, Hans Petter Selasky wrote:
> On 12/4/21 19:53, Steve Kargl wrote:
> > What to do about tgammal?

(trim some history)

> > 
> >Interval | Max ULP
> > ---+
> >   [6,171]   |  1340542.2
> >   [1.0662,6]|14293.3
> >   [1.01e-17,1.0661] | 3116.1
> >   [-1.,-1.0001] | 15330369.3
> > ---+
> > 
> > Well, I finally have gotten around to removing theraven@'s last kludge
> > for FreeBSD on systems that support ld80.  This is done with a straight
> > forward modification of the msun/bsdsrc code.  The limitation on
> > domain is removed and the accuracy substantially improved.
> > 
> >Interval | Max ULP
> > ---+--
> >   [6,1755]  |8.457
> >   [1.0662,6]|   11.710
> >   [1.01e-17,1.0661] |   11.689
> >   [-1.,-1.0001] |   11.871
> > ---+--
> > 
> > My modifications leverage the fact that tgamma(x) (ie., double function)
> > uses extend arithmetic to do the computations (approximately 85 bits of
> > precision).  To get the Max ULP below 1 (the desired upper limit), a few
> > minimax polynomials need to be determined and the mystery around a few
> > magic numbers need to be unraveled.
> > 
> > Extending what I have done to an ld128 implementation requires much
> > more effort than I have time and energy to pursue.  Someone with
> > interest in floating point math on ld128 system can provide an
> > implementation.
> > 
> > So, is anyone interested in seeing a massive patch?
> > 
> 
> Hi,
> 
> Do you need a implementation of tgamma() which is 100% correct, or a
> so-called speed-hack version of tgamma() which is almost correct?
> 
> I've looked a bit into libm in FreeBSD and I see some functions are
> implemented so that they execute quickly, instead of producing exact
> results. Is this true?
> 

I'm afraid that I don't fully understand your questions.

The ULP, listed above, were computed by comparing the libm tgammal(x)
against a tgammal(x) computed with MPFR.  The MPFR result was configured
to have 256 bits of precision.  In other words, MPFR is assumed to be
exact for the comparison between a 64-bit tgammal(x) and a 256-bit
mpfr_gamma() function.

There is no speed hack with mpfr_gamma().

% time ./tlibm_lmath -l -s 0 -x 6 -X 1755 -n 10 tgamma
Interval tested for tgammal: [6,1755]
10 calls, 0.042575 secs, 0.42575 usecs/call
count: 10
  xmu = LD80C(0xae3587b6f275c42c, 4,  2.17761377613776137760e+01L),
libmu = LD80C(0xb296591784078768,64,  2.57371418855839536160e+19L),
mpfru = LD80C(0xb296591784078760,64,  2.57371418855839536000e+19L),
 ULP = 8.28349
6.04 real 6.02 user 0.01 sys

My test program shows 10 libm tgammal(x) calls took about 0.04
seconds while the program takes 6 seconds to finish.  Most of that
time is dominated by MPFR.

In general, floating point arithmetic, where a finite number is
the result, is inexact.  The basic binary operators, +x-/*, are
specified by IEEE 754 to have an error no larger that 0.5 ULP.

The mantra that I follow (and know bde followed) is to try
to optimize libm functions to give the most accurate result
as fast as possible.

-- 
Steve

What to do about tgammal?

[Steve Kargl]

What to do about tgammal?

A long time ago (2013-09-06), theraven@ committed a kludge that mapped
several missing long double math functions to double math functions
(e.g., tanhl(x) was mapped to tanh(x)).  Over the next few years, I
(along with bde and das reviews) provided Intel 80-bit (ld80) and IEEE
128-bit (ld128) implementations for some of these functions; namely,
coshl(x), sinhl(x), tanhl(x), erfl(x), erfcl(x), and lgamma(x).  The
last remaining function is tgammal(x).  If one links a program that uses
tgammal(x) with libm, one sees

  /usr/local/bin/ld: fcn_list.o: in function `build_fcn_list':
  fcn_list.c:(.text+0x7c4): warning: tgammal has lower than advertised
  precision

The warning is actually misleading.  Not only does tgammal(x) have a
*MUCH* lower precision, it has a reduced domain.  That is, tgammal(x)
produces +inf for x > 172 whereas tgammal(x) should produce a finite
result for values of x up to 1755 (or so).  On amd64-*-freebsd,
testing 100 in the below intervals demonstrates pathetic accuracy.

Current implmentation via imprecise.c

  Interval | Max ULP
---+
 [6,171]   |  1340542.2
 [1.0662,6]|14293.3
 [1.01e-17,1.0661] | 3116.1
 [-1.,-1.0001] | 15330369.3
---+

Well, I finally have gotten around to removing theraven@'s last kludge
for FreeBSD on systems that support ld80.  This is done with a straight
forward modification of the msun/bsdsrc code.  The limitation on
domain is removed and the accuracy substantially improved. 

  Interval | Max ULP
---+--
 [6,1755]  |8.457
 [1.0662,6]|   11.710
 [1.01e-17,1.0661] |   11.689
 [-1.,-1.0001] |   11.871
---+--

My modifications leverage the fact that tgamma(x) (ie., double function)
uses extend arithmetic to do the computations (approximately 85 bits of
precision).  To get the Max ULP below 1 (the desired upper limit), a few
minimax polynomials need to be determined and the mystery around a few
magic numbers need to be unraveled.

Extending what I have done to an ld128 implementation requires much
more effort than I have time and energy to pursue.  Someone with 
interest in floating point math on ld128 system can provide an 
implementation.

So, is anyone interested in seeing a massive patch?

-- 
Steve

Re: WHY? commit ac76bc1145dd7f4476e5d982ce8f355f71015713

[Steve Kargl]

On Fri, Nov 05, 2021 at 03:14:46PM -0700, Steve Kargl wrote:
> On Fri, Nov 05, 2021 at 10:32:26PM +0100, Dimitry Andric wrote:
> > On 5 Nov 2021, at 21:13, Steve Kargl  
> > wrote:
> > > 
> > > Why was this committed?
> > > 
> > > commit ac76bc1145dd7f4476e5d982ce8f355f71015713
> > > Author: Dimitry Andric 
> > > Date:   Tue Feb 9 22:06:51 2021 +0100
> > > 
> > >Fix lib/msun's ctrig_test/test_inf_inputs test case with clang >= 10
> > > 
> > >This sprinkles a few strategic volatiles in an attempt to defeat 
> > > clang's
> > >optimization interfering with the expected floating-point exception
> > >flags.
> > > 
> > > There is nothing, and I mean, nothing strategic about "sprinkling"
> > > volatile onto the declaration of "float x, y, h;"  These variables
> > > are referenced in all floating pointing operations in the file,
> > > which means that there are needless reloading of x, y, and h
> > > from memory.
> > 
> > There was more context in https://bugs.freebsd.org/244732, but the gist
> > was that with clang >= 10, ctanh() and ctanhf() had FE_INVALID set after
> > calling them with {inf,inf}. The reasons for this were obscure to me at
> > the time, since it regressed with an llvm commit that seemed to have
> > very little to do with floating point.
> > 
> > However, in 3b00222f156d we added -fp-exception-behavior=maytrap to
> > clang's compile flags for lib/msun, for https://bugs.freebsd.org/254911,
> > to force it to use stricter floating point semantics. This turns out to
> > also make the admittedly ugly volatile fixes unnecessary.
> > 
> > So I have reverted ac76bc1145dd (minus the ctrig_test.c part) in:
> > https://cgit.freebsd.org/src/commit/?id=e2157cdf6dbb6465d7a885f2dcfd4d3596cb
> > 
> 
> Thanks for the explanation!  This would indeed be strange.
> The evaluation of ctanhf does not invoke ccoshf(z).
> 
> The relevant section of code from s_ctanh.c (similar code in s_ctanhf.c)
> is 
> 
>   if (ix >= 0x7ff0) {
>   if ((ix & 0xf) | lx)/* x is NaN */
>   return (CMPLX(nan_mix(x, y),
>   y == 0 ? y : nan_mix(x, y)));
>   SET_HIGH_WORD(x, hx - 0x4000);  /* x = copysign(1, x) */
>   return (CMPLX(x, copysign(0, isinf(y) ? y : sin(y) * cos(y;
>   }
> 
> The testcase should get to the second return statement.  So,
> either isinf(y) or copysign(0, inf) was raising the exception.
> 

I just scanned the llvm report pointed to in the FreeBSD bug
report.  The llvm report discusses changes in speculative
execution.  If clang was evaluating isinf(y) and either of
sin(y) or cos(y), speculatively, then yes, FE_INVALID will
be raised.

% tlibm_libm -e cos
cosf( 0) =  1.  Got no exception.  Expected 1 without exception.
cosf(-0) =  1.  Got no exception.  Expected 1 without exception.
cosf( inf) = nan.  Got FE_INVALID.  Expected nan with FE_INVALID.
cosf(-inf) = nan.  Got FE_INVALID.  Expected nan with FE_INVALID.
cos( 0) =  1.  Got no exception.  Expected 1 without exception.
cos(-0) =  1.  Got no exception.  Expected 1 without exception.
cos( inf) = nan.  Got FE_INVALID.  Expected nan with FE_INVALID.
cos(-inf) = nan.  Got FE_INVALID.  Expected nan with FE_INVALID.
cosl( 0) =  1.  Got no exception.  Expected 1 without exception.
cosl(-0) =  1.  Got no exception.  Expected 1 without exception.
cosl( inf) = nan.  Got FE_INVALID.  Expected nan with FE_INVALID.
cosl(-inf) = nan.  Got FE_INVALID.  Expected nan with FE_INVALID.

-- 
Steve

Re: WHY? commit ac76bc1145dd7f4476e5d982ce8f355f71015713

[Steve Kargl]

On Fri, Nov 05, 2021 at 10:32:26PM +0100, Dimitry Andric wrote:
> On 5 Nov 2021, at 21:13, Steve Kargl  
> wrote:
> > 
> > Why was this committed?
> > 
> > commit ac76bc1145dd7f4476e5d982ce8f355f71015713
> > Author: Dimitry Andric 
> > Date:   Tue Feb 9 22:06:51 2021 +0100
> > 
> >Fix lib/msun's ctrig_test/test_inf_inputs test case with clang >= 10
> > 
> >This sprinkles a few strategic volatiles in an attempt to defeat clang's
> >optimization interfering with the expected floating-point exception
> >flags.
> > 
> > There is nothing, and I mean, nothing strategic about "sprinkling"
> > volatile onto the declaration of "float x, y, h;"  These variables
> > are referenced in all floating pointing operations in the file,
> > which means that there are needless reloading of x, y, and h
> > from memory.
> 
> There was more context in https://bugs.freebsd.org/244732, but the gist
> was that with clang >= 10, ctanh() and ctanhf() had FE_INVALID set after
> calling them with {inf,inf}. The reasons for this were obscure to me at
> the time, since it regressed with an llvm commit that seemed to have
> very little to do with floating point.
> 
> However, in 3b00222f156d we added -fp-exception-behavior=maytrap to
> clang's compile flags for lib/msun, for https://bugs.freebsd.org/254911,
> to force it to use stricter floating point semantics. This turns out to
> also make the admittedly ugly volatile fixes unnecessary.
> 
> So I have reverted ac76bc1145dd (minus the ctrig_test.c part) in:
> https://cgit.freebsd.org/src/commit/?id=e2157cdf6dbb6465d7a885f2dcfd4d3596cb
> 

Thanks for the explanation!  This would indeed be strange.
The evaluation of ctanhf does not invoke ccoshf(z).

The relevant section of code from s_ctanh.c (similar code in s_ctanhf.c)
is 

if (ix >= 0x7ff0) {
if ((ix & 0xf) | lx)/* x is NaN */
return (CMPLX(nan_mix(x, y),
y == 0 ? y : nan_mix(x, y)));
SET_HIGH_WORD(x, hx - 0x4000);  /* x = copysign(1, x) */
return (CMPLX(x, copysign(0, isinf(y) ? y : sin(y) * cos(y;
}

The testcase should get to the second return statement.  So,
either isinf(y) or copysign(0, inf) was raising the exception.

-- 
Steve

WHY? commit ac76bc1145dd7f4476e5d982ce8f355f71015713

[Steve Kargl]

Why was this committed?

commit ac76bc1145dd7f4476e5d982ce8f355f71015713
Author: Dimitry Andric 
Date:   Tue Feb 9 22:06:51 2021 +0100

Fix lib/msun's ctrig_test/test_inf_inputs test case with clang >= 10

This sprinkles a few strategic volatiles in an attempt to defeat clang's
optimization interfering with the expected floating-point exception
flags.

There is nothing, and I mean, nothing strategic about "sprinkling"
volatile onto the declaration of "float x, y, h;"  These variables
are referenced in all floating pointing operations in the file,
which means that there are needless reloading of x, y, and h
from memory.

-- 
Steve

Re: [LIBM] One step closer to C99 conformance

[Steve Kargl]

On Fri, Nov 05, 2021 at 01:25:42PM -0400, Ed Maste wrote:
> On Thu, 4 Nov 2021 at 21:09, Steve Kargl
>  wrote:
> >
> > A patch has been attached to
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216862
> >
> > which implements cexpl().
> 
> Great, thank you Steve.
> 
> Do you have a list of what else is left for full C99? (Including
> anything that may be implemented in a suboptimal way today and should
> be redone.)

I have ccoshl and ccosl implemented, but need to do some testing.

Things that are missing ctanhl, ctanl, csinhl, and csinl.  I have an
old implementation of csinhl/csinl, but Bruce had some concerns with
handling of NaN and +-inf.  Need to dig up some old emails.

tgammal, powl, and cpow[fl] are a mess as the people who committed
code for these functions seem to have no interest in floating point
math on FreeBSD.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125

-- 
Steve

[LIBM] One step closer to C99 conformance

[Steve Kargl]

A patch has been attached to 

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216862

which implements cexpl().

Note, the patch includes some bug fixes for libm on
ld128 hardware.

-- 
Steve

Re: access to ld128 system

[Steve Kargl]

On Thu, Oct 28, 2021 at 03:28:51PM -0700, Steve Kargl wrote:
> kib@ recently committed my implementations of cospi[fl],
> sinpi[fl], and tanpi[fl].  These functions have been
> extensively tested for float, double, and long double
> where long double is the Intel 80-bit long double (e.g.,
> msun/ld80/s_sinpil.c).  The 128-bit versions of these
> routines have not been tested (e.g., msun/ld128/s_sinpil.c)
> 
> kib pointed me to a system in the FreeBSD, which I have
> access to.  Unfortunately, that system has double ==
> long double, and can only test the support for the
> weak references.
> 
> Is there a system with 128-bit long double that I can
> have access for some testing?
>  

FYI.  An individual has provided access to an aarch64
system.  A patch has been submitted to fix the ld128
sinpi, cospi, and tanpi.  For the record, I did limited
testing to not overwhelm the system.

The observed max ULP for sinpi and cospi were less than
1.1 ULP, which is slight worse that the desired less than 
1 ULP target.  This has been traced to the kernel for 
computing cosl() in the interval [0,pi/4].  I suspect
the minmax polynomial coefficients need refinement.

-- 
Steve

access to ld128 system

[Steve Kargl]

kib@ recently committed my implementations of cospi[fl],
sinpi[fl], and tanpi[fl].  These functions have been
extensively tested for float, double, and long double
where long double is the Intel 80-bit long double (e.g.,
msun/ld80/s_sinpil.c).  The 128-bit versions of these
routines have not been tested (e.g., msun/ld128/s_sinpil.c)

kib pointed me to a system in the FreeBSD, which I have
access to.  Unfortunately, that system has double ==
long double, and can only test the support for the
weak references.

Is there a system with 128-bit long double that I can
have access for some testing?
 
-- 
Steve

Re: Missing Copyright?

[Steve Kargl]

Warner,

Thanks for the quick response.

If I have time I'll rig up my build to disable the use of 
assembly routines on x86_64 and any compiler builtin functions
to do some testing of these routines.

On Fri, Oct 22, 2021 at 10:05:38PM -0600, Warner Losh wrote:
> Done.
> https://cgit.freebsd.org/src/commit/?id=3550a49f6814af38c21b0033ef8746953451dade
> 
> Since the license is a verbatim copy of the standard SPDX license, I tagged
> it using our draft license policy's
> suggested SPDX-License-Identifier: tag.
> 
> Warner
> 
> On Fri, Oct 22, 2021 at 9:14 PM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
> 
> > It seems that git commit f5542795b99206a2b4e5a57429d18b9478264e24
> > replaced the fdlibm implementations of s_scalbn.c, s_scalbnf.c,
> > and s_scalbnl.c by those in MUSL.  There are no Copyright
> > notices in these files.  There is no statement to the originals
> > of these files within the files.
> >
> > If one looks at https://git.musl-libc.org/cgit/musl/tree/COPYRIGHT
> > one finds:
> >
> > musl as a whole is licensed under the following standard MIT license:
> >

(trimmed)

-- 
Steve

Missing Copyright?

[Steve Kargl]

It seems that git commit f5542795b99206a2b4e5a57429d18b9478264e24
replaced the fdlibm implementations of s_scalbn.c, s_scalbnf.c,
and s_scalbnl.c by those in MUSL.  There are no Copyright 
notices in these files.  There is no statement to the originals
of these files within the files.

If one looks at https://git.musl-libc.org/cgit/musl/tree/COPYRIGHT
one finds:

musl as a whole is licensed under the following standard MIT license:

Copyright © 2005-2020 Rich Felker, et al.

Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Please add a Copyright to these files or remove them from the
repository to prevent someone from accidently violating said
Copyright.

-- 
Steve

Re: Future of ident(1)

[Steve Kargl]

On Fri, Oct 22, 2021 at 03:51:15PM -0600, Warner Losh wrote:
> On Fri, Oct 22, 2021 at 3:30 PM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
> 
> > All,
> >
> > With the new world order, what is the future of ident(1)?
> > Should it be removed from base?  Given a compiled binary
> > in base, how does one find the equivalent git info that
> > ident(1) used to perform?
> >
> 
> It is useful for some rare cases, but in general those cases likely
> can likely be handled by readelf / elfdump and adding build info
> to the files. I tendto think it's time to retire ident(1), but I'm in no
> hurry.
> 

I played a bit with objdump.  It seems currently a compiled object
and/or binary does not include a git hash.  I suppose this makes 
it only a bit more inconvenient to explore history.

> >
> > Having a few minutes to dust off old patchs for libm, should
> > I remove $FreeBSD$ tags in files I touch?
> 
> No. The current rule is that we're not removing $FreeBSD$ as we touch files.
> The plan is to remove it wholesale in the future. This gives maximum
> flexibility because stable/12 is still built out of svn and you never
> know what might get MFC'd there.
> 

OK.

> > For new files, is
> > it expected that useless $FreeBSD$ tags should be added?
> >
> 
> If you plan to or expet to merge the new file to stable/12, then yes.
> Otherwise omit $FreeBSD$. Most new files won't likely be merged to 12
> and even if you make an error in judgement and a new file without
> $FreeBSD$ is merged to 12, the impact is going to be minimal.

I have no intentions of merging anything.  I'll submit re-open a PR
and attach the updated to it.

-- 
Steve

Future of ident(1)

[Steve Kargl]

All,

With the new world order, what is the future of ident(1)?
Should it be removed from base?  Given a compiled binary
in base, how does one find the equivalent git info that
ident(1) used to perform?

Having a few minutes to dust off old patchs for libm, should
I remove $FreeBSD$ tags in files I touch?  For new files, is
it expected that useless $FreeBSD$ tags should be added?
 
-- 
Steve

Re: killall, symlinks, and signal delivery?

[Steve Kargl]

On Wed, Sep 08, 2021 at 02:10:47AM +0100, Jamie Landeg-Jones wrote:
> Steve Kargl  wrote:
> 
> > Yes, that's likely.  So, it could be a change in behavior
> > for ImageMagick.  Your suggested ps command doesn't provide
> 
> I don't know when the change was made, but the pkg for ImageMagik 6.9.12.12
> has "display" as a stand-alone binary, whilst the pkg for 7.0.11.12 has it
> as a softlink.
> 
> So yeah, either an upstream change, or a port change.
> 

Yes, indeed, we have a winner.  On my laptop, I have ImageMagick6 and
on my desktop ImagMagick7.  'killall display' works as expected on
mu laptop and fails on my desktop.

Thanks for the insights!

-- 
Steve

Re: killall, symlinks, and signal delivery?

[Steve Kargl]

On Tue, Sep 07, 2021 at 04:20:30PM -0700, Cy Schubert wrote:
> On September 7, 2021 3:42:53 PM PDT, Steve Kargl 
>  wrote:
> >I have stumbled about a quandry, which I hope someone
> >can shed some light upon.  In my day job, I often
> >generate a sequence of images and display these images
> >with ImageMagick's display command.  From my csh prompt,
> >a quick and dirty foreach() loop
> >
> >% foreach i (*.png)
> >> display $i &
> >> sleep 3
> >> end
> >
> >Instead of moving the cursor to each image and hitting
> >'q' to close the images.  I normally kill all of the
> >processes at one time.  This used to work:
> >
> >% killall display
> >
> >Now I geit, for example, 
> >
> >% display z.miff &
> >% killall display
> >No matching processes belonging to you were found
> >% ps -Ukargl | grep display
> >19463  1  S0:00.02 display z.miff (magick)
> >19465  1  S+   0:00.00 grep display
> >% ls -l /usr/local/bin/display 
> >lrwxr-xr-x  1 root  wheel  - 6 Jun  1 14:18 /usr/local/bin/display@ -> magick
> >
> >So, there are two possibilities:
> >(1) display was once an independent program and not a
> >symlink to magick.  Thus, killall just worked. Or,
> >(2) killall no longer works because command associated
> >with process 19463 is not really 'display' and the
> >symlink isn't resolved to actually kill 'magick'.
> >
> >So, just chekcing (2), here.  Is this a change in behvior
> >for FreeBSD?
> >
> 
> It's likely your app is replacing its process name
> (argv[0]) to something else. ps auxww may give you a
> hint what it might be now.

Yes, that's likely.  So, it could be a change in behavior
for ImageMagick.  Your suggested ps command doesn't provide
anything new.  ps shows the command that I entered, namely,
'display coarse_sand.jpg'.  But, it also shows '(magick)',
which is the actual name of the program.  I'm guessing
argv[0] = "magick".

% ps
24333  7  I 0:00.43 display coarse_sand.jpg (magick)

% killall magick

does the job of killing the displayed image.

-- 
Steve

killall, symlinks, and signal delivery?

[Steve Kargl]

I have stumbled about a quandry, which I hope someone
can shed some light upon.  In my day job, I often
generate a sequence of images and display these images
with ImageMagick's display command.  From my csh prompt,
a quick and dirty foreach() loop

% foreach i (*.png)
> display $i &
> sleep 3
> end

Instead of moving the cursor to each image and hitting
'q' to close the images.  I normally kill all of the
processes at one time.  This used to work:

% killall display

Now I geit, for example, 

% display z.miff &
% killall display
No matching processes belonging to you were found
% ps -Ukargl | grep display
19463  1  S0:00.02 display z.miff (magick)
19465  1  S+   0:00.00 grep display
% ls -l /usr/local/bin/display 
lrwxr-xr-x  1 root  wheel  - 6 Jun  1 14:18 /usr/local/bin/display@ -> magick

So, there are two possibilities:
(1) display was once an independent program and not a
symlink to magick.  Thus, killall just worked. Or,
(2) killall no longer works because command associated
with process 19463 is not really 'display' and the
symlink isn't resolved to actually kill 'magick'.

So, just chekcing (2), here.  Is this a change in behvior
for FreeBSD?

-- 
Steve

Re: BUG in libm's powf

[Steve Kargl]

On Mon, Sep 06, 2021 at 10:40:21PM +0200, Kurt Jaeger wrote:
> Hi!
> 
> > On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote:
> > > could you turn to test program into an AFT test to prevent further 
> > > regressions?
> > 
> > I cannot tell if you are addressing Mark or me.
> > For me, I know nothing about ATF.
> 
> man 7 atf
> 
> has more details.
> 

% man 7 atf
No manual entry for atf
% grep -i tests /etc/src.conf
WITHOUT_GOOGLETEST="YES"
WITHOUT_TESTS="YES"

-- 
Steve

Re: BUG in libm's powf

[Steve Kargl]

On Mon, Sep 06, 2021 at 10:22:02PM +0200, Gordon Bergling wrote:
> could you turn to test program into an AFT test to prevent further 
> regressions?
> 
> —Gordon
> 

I cannot tell if you are addressing Mark or me.
For me, I know nothing about ATF.  I do, however,
suspect that this won't regress as I'm one of the
few people who actually looks at threshold issues
in libm.

-- 
Steve

Re: BUG in libm's powf

[Steve Kargl]

No, thank you for the quick response.

Of course, a one character diff might be easier to review. :-)

-- 
steve 

On Mon, Sep 06, 2021 at 06:55:07PM +0100, Mark Murray wrote:
> Thanks!
> 
> And it's committed!
> 
> M
> 
> > On 6 Sep 2021, at 18:53, Steve Kargl  
> > wrote:
> > 
> > Fine with me.  I don't have a phabricator account and
> > bugzilla reports seems to get lost in the ether.
> > 
> > --
> > steve
> > 
> > On Mon, Sep 06, 2021 at 06:45:11PM +0100, Mark Murray wrote:
> >> Hi
> >> 
> >> I've opened a Phab ticket for this. I hope that's OK?
> >> 
> >> https://reviews.freebsd.org/D31865
> >> 
> >> M
> >> 
> >>> On 6 Sep 2021, at 16:28, Steve Kargl  
> >>> wrote:
> >>> 
> >>> Paul Zimmermann has identified a bug in Openlibm's powf(),
> >>> which is identical to FreeBSD's libm.  Both derived from
> >>> fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
> >>> 
> >>> Consider
> >>> 
> >>> % cat h.c
> >>> #include 
> >>> #include 
> >>> int
> >>> main(void)
> >>> {
> >>>  float x, y, z;
> >>>  x =  0x1.ecp-1F;
> >>>  y = -0x1.02p+27F;
> >>>  z =  0x1.557a86p115F;
> >>>  printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
> >>>  return 0;
> >>> }
> >>> 
> >>> % cc -o h -fno-builtin h.c -lm && ./h
> >>> 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
> >>> 
> >>> Note, clang seems to have a builtin for powf(), but one cannot
> >>> count of clang being the only consumer of libm.  With the patch
> >>> at the end of this email, I get
> >>> 
> >>> % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath && 
> >>> ./h
> >>> 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
> >>> 
> >>> Watch for copy and paste whitespace corruption.
> >>> 
> >>> --- /usr/src/lib/msun/src/e_powf.c2021-02-21 03:29:00.956878000 
> >>> -0800
> >>> +++ src/e_powf.c  2021-09-06 08:17:09.88000 -0700
> >>> @@ -136,7 +136,7 @@
> >>>/* |y| is huge */
> >>>   if(iy>0x4d00) { /* if |y| > 2**27 */
> >>>   /* over/underflow if x is not close to one */
> >>> - if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> >>> + if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> >>>   if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
> >>>   /* now |1-x| is tiny <= 2**-20, suffice to compute
> >>>  log(x) by x-x^2/2+x^3/3-x^4/4 */
> >>> 
> >>> 
> >>> --
> >>> Steve
> >>> 
> >> 
> >> --
> >> Mark R V Murray
> >> 
> > 
> > 
> > 
> > --
> > Steve
> > 
> 
> --
> Mark R V Murray
> 



-- 
Steve

Re: BUG in libm's powf

[Steve Kargl]

Fine with me.  I don't have a phabricator account and
bugzilla reports seems to get lost in the ether.

-- 
steve

On Mon, Sep 06, 2021 at 06:45:11PM +0100, Mark Murray wrote:
> Hi
> 
> I've opened a Phab ticket for this. I hope that's OK?
> 
> https://reviews.freebsd.org/D31865
> 
> M
> 
> > On 6 Sep 2021, at 16:28, Steve Kargl  
> > wrote:
> > 
> > Paul Zimmermann has identified a bug in Openlibm's powf(),
> > which is identical to FreeBSD's libm.  Both derived from
> > fdlibm. https://github.com/JuliaMath/openlibm/issues/212.
> > 
> > Consider
> > 
> > % cat h.c
> > #include 
> > #include 
> > int
> > main(void)
> > {
> >   float x, y, z;
> >   x =  0x1.ecp-1F;
> >   y = -0x1.02p+27F;
> >   z =  0x1.557a86p115F;
> >   printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
> >   return 0;
> > }
> > 
> > % cc -o h -fno-builtin h.c -lm && ./h
> > 9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34
> > 
> > Note, clang seems to have a builtin for powf(), but one cannot
> > count of clang being the only consumer of libm.  With the patch
> > at the end of this email, I get
> > 
> > % cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath && ./h
> > 9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34
> > 
> > Watch for copy and paste whitespace corruption.
> > 
> > --- /usr/src/lib/msun/src/e_powf.c  2021-02-21 03:29:00.956878000 -0800
> > +++ src/e_powf.c2021-09-06 08:17:09.88000 -0700
> > @@ -136,7 +136,7 @@
> > /* |y| is huge */
> > if(iy>0x4d00) { /* if |y| > 2**27 */
> > /* over/underflow if x is not close to one */
> > -   if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> > +   if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
> > if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
> > /* now |1-x| is tiny <= 2**-20, suffice to compute
> >log(x) by x-x^2/2+x^3/3-x^4/4 */
> > 
> > 
> > --
> > Steve
> > 
> 
> --
> Mark R V Murray
> 



-- 
Steve

BUG in libm's powf

[Steve Kargl]

Paul Zimmermann has identified a bug in Openlibm's powf(),
which is identical to FreeBSD's libm.  Both derived from
fdlibm. https://github.com/JuliaMath/openlibm/issues/212.

Consider

% cat h.c
#include 
#include 
int
main(void)
{
   float x, y, z;
   x =  0x1.ecp-1F;
   y = -0x1.02p+27F;
   z =  0x1.557a86p115F;
   printf("%e %e %e <-- should be %e\n", x, y, powf(x,y), z);
   return 0;
}

% cc -o h -fno-builtin h.c -lm && ./h
9.94e-01 -1.342177e+08 inf <-- should be 5.540807e+34

Note, clang seems to have a builtin for powf(), but one cannot
count of clang being the only consumer of libm.  With the patch
at the end of this email, I get

% cc -o h -fno-builtin h.c -L/home/kargl/trunk/math/libm/msun -lmath && ./h
9.94e-01 -1.342177e+08 5.540807e+34 <-- should be 5.540807e+34

Watch for copy and paste whitespace corruption.

--- /usr/src/lib/msun/src/e_powf.c  2021-02-21 03:29:00.956878000 -0800
+++ src/e_powf.c2021-09-06 08:17:09.88000 -0700
@@ -136,7 +136,7 @@
 /* |y| is huge */
if(iy>0x4d00) { /* if |y| > 2**27 */
/* over/underflow if x is not close to one */
-   if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
+   if(ix<0x3f76) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
/* now |1-x| is tiny <= 2**-20, suffice to compute
   log(x) by x-x^2/2+x^3/3-x^4/4 */


-- 
Steve

Re: Fwd: Information for freebsd-current@FreeBSD.org

[Steve Kargl]

The mailing lists are migrating from mailman to Mlmmj.  I
suspect, but haven't verified, that this is the new norm
for the monthly notice about mailing list subscriptions.

I would suggesting reading the mailing list archives,
but needs to guess where the relevent discussion might
be found.  If you got here:

https://www.freebsd.org/community/mailinglists/

You'll find

   You can *search* or *browse* the mailing list archives.
   At the current time, archives prior to May 2021 are *in
   a separate archive.*

where *search*, *browse* and *in a separate archive.* are
hyperlinks.  This is quite misleading as at least

dev-commits-doc-all/-   2021-Jul-02 03:27
dev-commits-ports-all/  -   2021-Jul-01 03:27
dev-commits-ports-branches/ -   2021-Jul-04 03:27
dev-commits-ports-main/ -   2021-Jul-01 03:27
dev-commits-src-all/-   2021-Jul-02 03:27
dev-commits-src-branches/   -   2021-Jul-03 03:27
dev-commits-src-main-   2021-Jul-03 03:27

are under *in a separate archive*, which clearly shows
messages newer than the May 2021 date are not archived
under *browse*.  There are a few other archives that 
violate the statement on the FreeBSD.org.


-- 
steve

On Thu, Jul 29, 2021 at 05:39:04PM +0200, Matthias Apitz wrote:
> 
> Is this a phishing attack or did I missed some change in the FBSD
> mailing lists?
> 
>   matthias
> 
> - Forwarded message from freebsd-current+ow...@freebsd.org -
> 
> Date: Thu, 29 Jul 2021 15:00:41 +
> From: freebsd-current+ow...@freebsd.org
> To: freebsd-current@FreeBSD.org
> Subject: Information for freebsd-current@FreeBSD.org
> 
> Hi, this is the Mlmmj program managing the 
> mailing list.
> 
> Here is some information about the list.
> 
> You can subscribe to the following versions:
> 
> - The normal version: Every time a post is sent to the list, subscribers
>   receive a copy of it. Subscribe by emailing
>   .
> 
> - The digest version: Subscribers receive multiple posts in a single mail
>   message, at regular intervals, or when a lot of posts have accumulated.
>   Subscribe by emailing .
> 
> - The no-mail version: Subscribers do not receive any posts to the list.
>   This means, though, they are able to post to a list which only
>   subscribers may post to, while they follow the list using a web archive
>   or another subscribed email address. Subscribe by emailing
>   .
> 
> Unsubscribe by emailing .
> 
> Posts are made by emailing .
> 
> However, only subscribers may post to the list.
> 
> The list also has access rules which may affect who can post and which
> posts are moderated.
> 
> Subscribers can retrieve message number N from the list's archive by
> sending a message to  (change the N to
> the number of the desired message).
> 
> You can retrieve the frequently asked questions document for the list by
> sending a message to .
> 
> To contact the list owner, send a message to
> .
> 
> 
> 
> - End forwarded message -
> 
> -- 
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
> Tear it down! Defund the Humboldt Forum!
> https://www.jungewelt.de/artikel/406715.humboldt-forum-feudaler-themenpark.html
> 

-- 
Steve

Re: panic: vm_domainset_iter_first: Unknown policy 15168

[Steve Kargl]

On Tue, Jul 20, 2021 at 02:36:39PM -0400, Mark Johnston wrote:
> 
> I see, it looks like there is some generic memory corruption triggered
> by the UDF implementation.  Our implementation is fairly stale,
> unfortunately, but it shouldn't trigger a panic.
>`
> If you don't already have INVARIANTS configured, that would probably
> help narrow this down.  If you're able to share the image that can
> trigger this, I could try to debug from that.

Don't have invariants configured.  I can update my kernel
config and recompile tomorrow.

For debugging purposes, do you only need kernel.debug
and vmcore.2, or do you also need the loaded modules?

-- 
Steve

Re: panic: vm_domainset_iter_first: Unknown policy 15168

[Steve Kargl]

On Tue, Jul 20, 2021 at 12:15:58PM -0400, Mark Johnston wrote:
> On Tue, Jul 20, 2021 at 09:07:04AM -0700, Steve Kargl wrote:
> > On Mon, Jul 19, 2021 at 07:05:03PM -0700, Steve Kargl wrote:
> > > On Mon, Jul 19, 2021 at 07:55:07PM -0400, Mark Johnston wrote:
> > > > On Mon, Jul 19, 2021 at 03:02:19PM -0700, Steve Kargl wrote:
> > > > > 
> > > > > (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> > > > > #1  doadump (textdump=textdump@entry=1)
> > > > > at /usr/src/sys/kern/kern_shutdown.c:399
> > > > > #2  0x805fe263 in kern_reboot (howto=260)
> > > > > at /usr/src/sys/kern/kern_shutdown.c:486
> > > > > #3  0x805fe6b0 in vpanic (fmt=, ap= > > > > out>)
> > > > > at /usr/src/sys/kern/kern_shutdown.c:919
> > > > > #4  0x805fe4b3 in panic (fmt=)
> > > > > at /usr/src/sys/kern/kern_shutdown.c:843
> > > > > #5  0x8085dcbb in vm_domainset_iter_first (di= > > > > out>, 
> > > > > domain=) at /usr/src/sys/vm/vm_domainset.c:189
> > > > > #6  0x8085dbd2 in vm_domainset_iter_page_init (
> > > > > di=di@entry=0xfe012ae5e2a0, obj=obj@entry=0xf8003c21f420, 
> > > > > pindex=, pindex@entry=16931, 
> > > > > domain=domain@entry=0xfe012ae5e2f4, req=, 
> > > > > req@entry=0xfe012ae5e2f0) at 
> > > > > /usr/src/sys/vm/vm_domainset.c:217
> > > > 
> > > > Could you please show output from:
> > > > 
> > > > (kgdb) frame 6
> > > > (kgdb) p *dr
> > > > (kgdb) p obj->domain
> > > > 
> > > 
> > > The system is at work.  I'll do this tomorrow morning.
> > > Thanks for asking for additional info.
> > >
> > 
> > Hi Mark, I poked around and tried to supply the request info
> > along with content of other structs. 
> > 
> > (kgdb) frame 6
> > #6  0x8085dbd2 in vm_domainset_iter_page_init (
> > di=di@entry=0xfe012ae5e2a0, obj=obj@entry=0xf8003c21f420, 
> > pindex=, pindex@entry=16931, 
> > domain=domain@entry=0xfe012ae5e2f4, req=, 
> > req@entry=0xfe012ae5e2f0) at /usr/src/sys/vm/vm_domainset.c:217
> > 217 vm_domainset_iter_first(di, domain);
> > (kgdb) p *dr
> > value has been optimized out
> > (kgdb) p obj->domain
> > $1 = {dr_policy = 0xf800064b9c60, dr_iter = 0}
> > (kgdb) p *obj->domain->dr_policy 
> > $3 = {ds_link = {le_next = 0xf8003c21f420, le_prev = 
> > 0xfe000ce71188}, 
> >   ds_mask = {__bits = {0}}, ds_policy = 15168, ds_prefer = 231 '\347', 
> >   ds_cnt = 12 '\f', 
> >   ds_order = "\000\376\377\377@", }
> > (kgdb) p *di
> > $8 = {di_domain = 0xf800064b9c60, di_iter = 0xf8003c21f490, 
> >   di_offset = 35190825029656, di_flags = 86066, di_policy = 15168, 
> >   di_n = 255 '\377', di_minskip = true}
> 
> So the object somehow ended up referencing a bogus domainset.  Could you
> please also show
> 
> (kgdb) p *obj
> (kgdb) p vnode_domainset
>

(kgdb) p *obj
$1 = {lock = {lock_object = {lo_name = 0x8092d720 "vm object", 
  lo_flags = 627245056, lo_data = 0, lo_witness = 0x0}, 
rw_lock = 18446741878362575616}, object_list = {
tqe_next = 0xf8003c21f528, tqe_prev = 0xf8003c21f338}, 
  shadow_head = {lh_first = 0x0}, shadow_list = {le_next = 0x0, 
le_prev = 0x0}, memq = {tqh_first = 0xfe000d44b290, 
tqh_last = 0xfe000d418a30}, rtree = {rt_root = 18446735285712745888}, 
  size = 527600, domain = {dr_policy = 0xf800064b9c60, dr_iter = 0}, 
  generation = 1, cleangeneration = 1, ref_count = 0, shadow_count = 0, 
  memattr = 6 '\006', type = 2 '\002', flags = 0, pg_color = 0, 
  paging_in_progress = {__count = 0}, busy = {__count = 0}, 
  resident_page_count = 5383, backing_object = 0x0, backing_object_offset = 0, 
  pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {
lh_first = 0x0}, handle = 0xf801e23d3380, un_pager = {vnp = {
  vnp_size = 2161049600, writemappings = 0}, devp = {devp_pglist = {
tqh_first = 0x80cf, tqh_last = 0x0}, ops = 0x0, dev = 0x0}, sgp = {
  sgp_pglist = {tqh_first = 0x80cf, tqh_last = 0x0}}, swp = {
  swp_tmpfs = 0x80cf, swp_blks = {pt_root = 0}, writemappings = 0}, 
phys = {ops = 0x80cf, {data_ptr = 0x0, data_val = 0}}}, cred = 0x0, 
  charge = 0, umtx_data = 0x0}
(kgdb) p vnode_domainset
$2 = (struct domainset *) 0x0
>

Re: panic: vm_domainset_iter_first: Unknown policy 15168

[Steve Kargl]

On Mon, Jul 19, 2021 at 07:05:03PM -0700, Steve Kargl wrote:
> On Mon, Jul 19, 2021 at 07:55:07PM -0400, Mark Johnston wrote:
> > On Mon, Jul 19, 2021 at 03:02:19PM -0700, Steve Kargl wrote:
> > > 
> > > (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> > > #1  doadump (textdump=textdump@entry=1)
> > > at /usr/src/sys/kern/kern_shutdown.c:399
> > > #2  0x805fe263 in kern_reboot (howto=260)
> > > at /usr/src/sys/kern/kern_shutdown.c:486
> > > #3  0x805fe6b0 in vpanic (fmt=, ap=)
> > > at /usr/src/sys/kern/kern_shutdown.c:919
> > > #4  0x805fe4b3 in panic (fmt=)
> > > at /usr/src/sys/kern/kern_shutdown.c:843
> > > #5  0x8085dcbb in vm_domainset_iter_first (di=, 
> > > domain=) at /usr/src/sys/vm/vm_domainset.c:189
> > > #6  0x8085dbd2 in vm_domainset_iter_page_init (
> > > di=di@entry=0xfe012ae5e2a0, obj=obj@entry=0xf8003c21f420, 
> > > pindex=, pindex@entry=16931, 
> > > domain=domain@entry=0xfe012ae5e2f4, req=, 
> > > req@entry=0xfe012ae5e2f0) at /usr/src/sys/vm/vm_domainset.c:217
> > 
> > Could you please show output from:
> > 
> > (kgdb) frame 6
> > (kgdb) p *dr
> > (kgdb) p obj->domain
> > 
> 
> The system is at work.  I'll do this tomorrow morning.
> Thanks for asking for additional info.
>

Hi Mark, I poked around and tried to supply the request info
along with content of other structs. 

(kgdb) frame 6
#6  0x8085dbd2 in vm_domainset_iter_page_init (
di=di@entry=0xfe012ae5e2a0, obj=obj@entry=0xf8003c21f420, 
pindex=, pindex@entry=16931, 
domain=domain@entry=0xfe012ae5e2f4, req=, 
req@entry=0xfe012ae5e2f0) at /usr/src/sys/vm/vm_domainset.c:217
217 vm_domainset_iter_first(di, domain);
(kgdb) p *dr
value has been optimized out
(kgdb) p obj->domain
$1 = {dr_policy = 0xf800064b9c60, dr_iter = 0}
(kgdb) p *obj->domain->dr_policy 
$3 = {ds_link = {le_next = 0xf8003c21f420, le_prev = 0xfe000ce71188}, 
  ds_mask = {__bits = {0}}, ds_policy = 15168, ds_prefer = 231 '\347', 
  ds_cnt = 12 '\f', 
  ds_order = "\000\376\377\377@", }
(kgdb) p *di
$8 = {di_domain = 0xf800064b9c60, di_iter = 0xf8003c21f490, 
  di_offset = 35190825029656, di_flags = 86066, di_policy = 15168, 
  di_n = 255 '\377', di_minskip = true}

-- 
Steve

Re: panic: vm_domainset_iter_first: Unknown policy 15168

[Steve Kargl]

On Mon, Jul 19, 2021 at 07:55:07PM -0400, Mark Johnston wrote:
> On Mon, Jul 19, 2021 at 03:02:19PM -0700, Steve Kargl wrote:
> > 
> > (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> > #1  doadump (textdump=textdump@entry=1)
> > at /usr/src/sys/kern/kern_shutdown.c:399
> > #2  0x805fe263 in kern_reboot (howto=260)
> > at /usr/src/sys/kern/kern_shutdown.c:486
> > #3  0x805fe6b0 in vpanic (fmt=, ap=)
> > at /usr/src/sys/kern/kern_shutdown.c:919
> > #4  0x805fe4b3 in panic (fmt=)
> > at /usr/src/sys/kern/kern_shutdown.c:843
> > #5  0x8085dcbb in vm_domainset_iter_first (di=, 
> > domain=) at /usr/src/sys/vm/vm_domainset.c:189
> > #6  0x8085dbd2 in vm_domainset_iter_page_init (
> > di=di@entry=0xfe012ae5e2a0, obj=obj@entry=0xf8003c21f420, 
> > pindex=, pindex@entry=16931, 
> > domain=domain@entry=0xfe012ae5e2f4, req=, 
> > req@entry=0xfe012ae5e2f0) at /usr/src/sys/vm/vm_domainset.c:217
> 
> Could you please show output from:
> 
> (kgdb) frame 6
> (kgdb) p *dr
> (kgdb) p obj->domain
> 

The system is at work.  I'll do this tomorrow morning.
Thanks for asking for additional info.

-- 
Steve

panic: vm_domainset_iter_first: Unknown policy 15168

[Steve Kargl]

While reading files from a UDF filesystem, I 
received the following panic.  I have the core
file and kernel if anyone is interested.


Unread portion of the kernel message buffer:
panic: vm_domainset_iter_first: Unknown policy 15168
cpuid = 2
time = 1626730195
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe012ae5e1a0
vpanic() at vpanic+0x181/frame 0xfe012ae5e1f0
panic() at panic+0x43/frame 0xfe012ae5e250
vm_domainset_iter_first() at vm_domainset_iter_first+0xab/frame 
0xfe012ae5e260
vm_domainset_iter_page_init() at vm_domainset_iter_page_init+0xc2/frame 
0xfe012ae5e290
vm_page_grab_pages() at vm_page_grab_pages+0x155/frame 0xfe012ae5e330
vm_page_grab_pages_unlocked() at vm_page_grab_pages_unlocked+0x1b0/frame 
0xfe012ae5e390
allocbuf() at allocbuf+0x38b/frame 0xfe012ae5e400
getblkx() at getblkx+0x58c/frame 0xfe012ae5e4c0
breadn_flags() at breadn_flags+0x42/frame 0xfe012ae5e520
udf_vget() at udf_vget+0x1c2/frame 0xfe012ae5e5c0
udf_lookup() at udf_lookup+0x442/frame 0xfe012ae5e670
vfs_cache_lookup() at vfs_cache_lookup+0xa4/frame 0xfe012ae5e6c0
lookup() at lookup+0x65f/frame 0xfe012ae5e760
namei() at namei+0x216/frame 0xfe012ae5e810
kern_statat() at kern_statat+0xe1/frame 0xfe012ae5e940
sys_fstatat() at sys_fstatat+0x2f/frame 0xfe012ae5ea40
amd64_syscall() at amd64_syscall+0xe0/frame 0xfe012ae5eb70
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe012ae5eb70
--- syscall (552, FreeBSD ELF64, sys_fstatat), rip = 0x2011a12fa, rsp = 
0x7fffe0c8, rbp = 0x7fffe180 ---
Uptime: 19m58s

(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=textdump@entry=1)
at /usr/src/sys/kern/kern_shutdown.c:399
#2  0x805fe263 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:486
#3  0x805fe6b0 in vpanic (fmt=, ap=)
at /usr/src/sys/kern/kern_shutdown.c:919
#4  0x805fe4b3 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:843
#5  0x8085dcbb in vm_domainset_iter_first (di=, 
domain=) at /usr/src/sys/vm/vm_domainset.c:189
#6  0x8085dbd2 in vm_domainset_iter_page_init (
di=di@entry=0xfe012ae5e2a0, obj=obj@entry=0xf8003c21f420, 
pindex=, pindex@entry=16931, 
domain=domain@entry=0xfe012ae5e2f4, req=, 
req@entry=0xfe012ae5e2f0) at /usr/src/sys/vm/vm_domainset.c:217
#7  0x80879b25 in vm_page_alloc_after (object=0xf8003c21f420, 
pindex=16931, req=118818, mpred=0xfe000ce709b0)
at /usr/src/sys/vm/vm_page.c:2008
#8  vm_page_grab_pages (object=object@entry=0xf8003c21f420, 
pindex=pindex@entry=16931, allocflags=, 
ma=0xfe001c1c9a90, count=1) at /usr/src/sys/vm/vm_page.c:4800
#9  0x80879f90 in vm_page_grab_pages_unlocked (
object=, pindex=16931, allocflags=allocflags@entry=4642, 
ma=0xfe001c1c9a90, ma@entry=, count=)
at /usr/src/sys/vm/vm_page.c:4862
#10 0x806a2eab in vfs_vmio_extend (bp=0xfe001c1c9960, 
desiredpages=0, size=) at /usr/src/sys/kern/vfs_bio.c:3095
#11 allocbuf (bp=bp@entry=0xfe001c1c9960, size=size@entry=2048)
at /usr/src/sys/kern/vfs_bio.c:4337
#12 0x806a137c in getblkx (vp=, 
vp@entry=0xf801e23d3380, blkno=, 
dblkno=, size=2048, slpflag=, 
slpflag@entry=0, slptimeo=slptimeo@entry=0, flags=, 
bpp=0xfe012ae5e4e8) at /usr/src/sys/kern/vfs_bio.c:4172
#13 0x806a0c72 in breadn_flags (vp=, 
blkno=, dblkno=, size=, 
rablkno=, rablkno@entry=0x0, rabsize=, 
rabsize@entry=0x0, cnt=0, cred=0x0, flags=0, ckhashfunc=0x0, 
bpp=0xfe012ae5e580) at /usr/src/sys/kern/vfs_bio.c:2176
#14 0x8056ecc2 in udf_vget (mp=, ino=ino@entry=33574, 
flags=, flags@entry=2105344, 
vpp=vpp@entry=0xfe012ae5e630) at /usr/src/sys/fs/udf/udf_vfsops.c:646
#15 0x805707f2 in udf_lookup (a=, 
a@entry=)
at /usr/src/sys/fs/udf/udf_vnops.c:1227
#16 0x806aa3a4 in VOP_CACHEDLOOKUP (dvp=0xf80216c1ee00, 
vpp=0xfe012ae5e878, cnp=0xfe012ae5e8a0) at ./vnode_if.h:99
#17 vfs_cache_lookup (ap=, 
ap@entry=)
at /usr/src/sys/kern/vfs_cache.c:3041
#18 0x806b62ff in VOP_LOOKUP (dvp=0xf80216c1ee00, 
vpp=0xfe012ae5e878, cnp=0xfe012ae5e8a0) at ./vnode_if.h:65
#19 lookup (ndp=ndp@entry=0xfe012ae5e820)
at /usr/src/sys/kern/vfs_lookup.c:1116
#20 0x806b54a6 in namei (ndp=ndp@entry=0xfe012ae5e820)
at /usr/src/sys/kern/vfs_lookup.c:661
#21 0x806d0dc1 in kern_statat (td=0xfe00db1f9300, 
flag=, fd=, path=, 
pathseg=, pathseg@entry=UIO_USERSPACE, 
sbp=sbp@entry=0xfe012ae5e958, hook=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:2423
#22 0x806d1a6f in sys_fstatat (td=, 
uap=0xfe00db1f96e8) at /usr/src/sys/kern/vfs_syscalls.c:2400
#23 0x808e2240 in syscallenter (td=0xfe00db1f9300)
at /usr/src/sys/amd64/amd64/../..

Re: Files in /etc containing empty VCSId header

[Steve Kargl]

On Thu, Jun 10, 2021 at 03:26:58PM -0700, Kevin Oberman wrote:
> On Wed, Jun 9, 2021 at 2:02 AM Michael Gmelin  wrote:
> >
> > > On 9. Jun 2021, at 01:15, Ian Lepore  wrote:
> > >
> > > On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
> > >>> On Tue, 8 Jun 2021 09:41:34 +
> > >>> Mark Linimon  wrote:
> > >>>
> >  On Mon, Jun 07, 2021 at 01:58:01PM -0600, Ian Lepore wrote:
> > > Sometimes it's a real interesting exercise to figure out where
> > > a
> > > file on your runtime system comes from in the source world.
> > >>
> > >> There is a command for that which does or use to do a pretty
> > >> decent job of it called whereis(1).
> > >>
> > >
> > > revolution > whereis ntp.conf
> > > ntp.conf:
> > > revolution > whereis netif
> > > netif:
> >
> > That line might make it to a shirt one day:
> >
> > > revolution > whereis services
> >
> > ;)
> > Michael
> >
> Just to clarify for those not willing or able to RTFM, it only works for
> executables, not conf files or libraries. It reports the location of the
> executable, the man page and the port location, if it is a port. For those
> who did RTFM, it is wrong. It claims that it reports on the location of the
> source, but that is not the case as far as I know. I have never seen it
> return anything from /usr/src.
> > whereis cc
> cc: /usr/bin/cc /usr/share/man/man1/cc.1.gz
> > whereis postfix
> postfix: /usr/local/sbin/postfix /usr/local/man/man1/postfix.1.gz
> /usr/ports/mail/postfix

I should probably just lurk, but I believe the command that
some are looking for is ident(1).  This command is, of course,
broken by the lost of $FreeBSD$ expansion.

-- 
Steve

Re: What happen to mailing list archives?

[Steve Kargl]

On Sun, Jun 06, 2021 at 01:04:46AM +0200, Michael Gmelin wrote:
> 
> p.s. If you go to https://lists.freebsd.org/mailman/listinfo, click 
> FreeBSD-net and then "Archives from mailman’s time", you get to a list that 
> brings you to https://lists.freebsd.org/pipermail/freebsd-net/. So the old 
> archives are still reachable that way. (I still find the 
> docs.FreeBSD.org/mail page to be confusing).
> 
> 

There isn't an "Archives from mailman's time" link on freebsd-numerics.

Hundreds of emails from me are now gone or sufficiently hidden that
I cannot find them.  More importantly, Bruce Evans often replied
with reviews of libm patch's I sent the list.  Those reviews and
his detailed analysis of the libm code are now gone or sufficiently
hidded that I cannot find them.

-- 
Steve

Re: What happen to mailing list archives?

[Steve Kargl]

On Sun, Jun 06, 2021 at 01:00:40AM +0200, Michael Gmelin wrote:
> 
> 
> > On 6. Jun 2021, at 00:53, Steve Kargl  
> > wrote:
> > 
> > It seems someone has tried to migrate the mailing list archives
> > from mailman to some new fangle code.  This has broken the archives
> > for at least freebsd-numerics@, freebsd-office@, freebsd-net@
> > 
> > As a comparison, simply go to
> > 
> > https://lists.freebsd.org/mailman/listinfo
> > 
> > and follow the links to freebsd-numerics and freebsd-toolchain.
> > 
> > Can this be fixed?
> > 
> 
> New archives are here:
> https://lists.freebsd.org/archives/
> 

If I go to https://www.freebsd.org/community/mailinglists/

I see the lines

  Mailing list archives

  You can search or browse the mailing list archives at www.FreeBSD.org.
  It is also possible to browse the mailing lists via the Mailman Web
  interface.

Both instances of the word "browse" are hyperlinks.  If I click of the
second "browse" link, then I end up at

https://lists.freebsd.org/mailman/listinfo

which presents a list of archives, you'll see freebsd-numerics
is a hyperlink (as well as many others).  If I click on freebsd-numerics,
this takes me to

https://lists.freebsd.org/subscription/freebsd-numerics

which displays

  Subscription for freebsd-numerics

 Browse the archives:   here
 (and 6 hyperlinks for subscribing and unsubscribing).

If I click on "here", I get

404 Not Found

Ergo, the freebsd-numerics archive is unreachable from the "here" link.
Shouldn't this redirect to the new fangle way?

-- 
Steve

What happen to mailing list archives?

[Steve Kargl]

It seems someone has tried to migrate the mailing list archives
from mailman to some new fangle code.  This has broken the archives
for at least freebsd-numerics@, freebsd-office@, freebsd-net@

As a comparison, simply go to

https://lists.freebsd.org/mailman/listinfo

and follow the links to freebsd-numerics and freebsd-toolchain.

Can this be fixed?

-- 
Steve

Re: FreeBSD - rc.conf man page splitting.

[Steve Kargl]

On Sun, May 23, 2021 at 09:20:45PM +0100, Santiago Martinez wrote:
> 
> Just wondering whats your view on splitting rc.conf man pages (per
> section/topic), something similar to what it was done with zfs.
> 
> For example rc.conf-fw, rc.conf-network and so on. And yes if people think
> is a good idea im happy to take the task.
> 

IMO, Bad idea (tm).

-- 
Steve

Re: cardbus panic

[Steve Kargl]

That fixes the problem.  Thanks for the quick response.

-- 
steve

On Sat, Feb 27, 2021 at 12:02:54AM -0700, Warner Losh wrote:
> What does https://reviews.freebsd.org/D28963 do for you?
> 
> Warner
> 
> On Fri, Feb 26, 2021 at 9:48 PM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
> 
> > Ejecting a D-Link DWL-G630 AirPlus G NIC leads to
> >
> > panic: mutex Giant not owned at /usr/src/sys/kern/subr_bus.c:3001
> > cpuid = 1
> > time = 1614400775
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfe0062fc3b40
> > vpanic() at vpanic+0x181/frame 0xfe0062fc3b90
> > panic() at panic+0x43/frame 0xfe0062fc3bf0
> > __mtx_assert() at __mtx_assert+0xb0/frame 0xfe0062fc3c00
> > device_detach() at device_detach+0x2e/frame 0xfe0062fc3c40
> > bus_generic_detach() at bus_generic_detach+0x38/frame 0xfe0062fc3c60
> > cardbus_detach_card() at cardbus_detach_card+0xf/frame 0xfe0062fc3c80
> > cbb_event_thread() at cbb_event_thread+0x1be/frame 0xfe0062fc3cf0
> > fork_exit() at fork_exit+0x80/frame 0xfe0062fc3d30
> > fork_trampoline() at fork_trampoline+0xe/frame 0xfe0062fc3d30
> > --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > KDB: enter: panic
> >

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

cardbus panic

[Steve Kargl]

Ejecting a D-Link DWL-G630 AirPlus G NIC leads to

panic: mutex Giant not owned at /usr/src/sys/kern/subr_bus.c:3001
cpuid = 1
time = 1614400775
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0062fc3b40
vpanic() at vpanic+0x181/frame 0xfe0062fc3b90
panic() at panic+0x43/frame 0xfe0062fc3bf0
__mtx_assert() at __mtx_assert+0xb0/frame 0xfe0062fc3c00
device_detach() at device_detach+0x2e/frame 0xfe0062fc3c40
bus_generic_detach() at bus_generic_detach+0x38/frame 0xfe0062fc3c60
cardbus_detach_card() at cardbus_detach_card+0xf/frame 0xfe0062fc3c80
cbb_event_thread() at cbb_event_thread+0x1be/frame 0xfe0062fc3cf0
fork_exit() at fork_exit+0x80/frame 0xfe0062fc3d30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0062fc3d30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
pcpu,
(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=-1772142592) at /usr/src/sys/kern/kern_shutdown.c:399
#2  0x80438f9e in db_fncall_generic (addr=, 
rv=, nargs=0, args=)
at /usr/src/sys/ddb/db_command.c:610
#3  db_fncall (dummy1=, dummy2=, 
dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:658
#4  0x80438ab0 in db_command (last_cmdp=, 
cmd_table=, dopager=dopager@entry=1)
at /usr/src/sys/ddb/db_command.c:482
#5  0x8043880d in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:535
#6  0x8043bb76 in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:270
#7  0x80750714 in kdb_trap (type=type@entry=3, code=code@entry=0, 
tf=, tf@entry=0xfe0062fc3a70)
at /usr/src/sys/kern/subr_kdb.c:727
#8  0x80a7af3e in trap (frame=0xfe0062fc3a70)
at /usr/src/sys/amd64/amd64/trap.c:576
#9  
#10 kdb_enter (why=0x80b4ad3c "panic", msg=)
at /usr/src/sys/kern/subr_kdb.c:506
#11 0x80704682 in vpanic (fmt=, ap=, 
ap@entry=0xfe0062fc3bd0) at /usr/src/sys/kern/kern_shutdown.c:907
#12 0x80704413 in panic (
fmt=0x80eb3230  
"\vb\254\200\377\377\377\377\n") at /usr/src/sys/kern/kern_shutdown.c:843
#13 0x806e14d0 in __mtx_assert (c=, 
what=, file=0xfe0062fc3a30 "", line=-2135709212)
at /usr/src/sys/kern/kern_mutex.c:1086
#14 0x8073cc8e in device_detach (dev=dev@entry=0xf8000540a500)
at /usr/src/sys/kern/subr_bus.c:3001
#15 0x8073f9e8 in bus_generic_detach (dev=)
at /usr/src/sys/kern/subr_bus.c:3761
#16 0x8050e6ef in cardbus_detach_card (cbdev=0xf80003021e00)
at /usr/src/sys/dev/cardbus/cardbus.c:259
#17 0x80555eae in CARD_DETACH_CARD (dev=0xf80003021e00)
at ./card_if.h:106
#18 cbb_removal (sc=0xf8000305d400) at /usr/src/sys/dev/pccbb/pccbb.c:581
#19 cbb_event_thread (arg=arg@entry=0xf8000305d400)
at /usr/src/sys/dev/pccbb/pccbb.c:474
#20 0x806bfc60 in fork_exit (
callout=0x80555cf0 , arg=0xf8000305d400, 
frame=0xfe0062fc3d40) at /usr/src/sys/kern/kern_fork.c:1069
#21 

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: any images for freebsd-current?

[Steve Kargl]

On Mon, Feb 08, 2021 at 03:03:10AM +, Glen Barber wrote:
> On Sat, Feb 06, 2021 at 11:59:27AM -0800, Steve Kargl wrote:
> > Any one aware of where images from freebsd-current?
> > freebsd.org appears to offer no images.
> > 
> 
> Some juggling needs to be done to the release build machines, which
> I hope to have done this week before the weekly snapshots.
> 

FYI.  I downloaded the 20210218 memstick image for FreeBSD-14
amd64, and re-installed FreeBSD on the problematic laptop.  So
far, the laptop has been rock solid.  Rebuilt 547 ports from 
source.

I suspect that there is vm or ufs or clang/llvm bug(s) that
make running FreeBSD i386 on this laptop a nightmare.  From 
early Jan 2021 until this passed weekend, I was having daily
(sometime multiple) panics.  Panics pointed at issues with
vm (but required drm-kmod to be loaded) and massively scrambled
my SU ufs filesystems.  I also know that clang miscompiles
libm, so by extension it may be miscompiling others parts of
FreeBSD (leading to the panics).  YMMV.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADSUP: math is broken with clang and optimization

[Steve Kargl]

On Mon, Feb 15, 2021 at 03:27:08PM -0800, Mark Millard wrote:
> > On Mon, Feb 15, 2021 at 01:03:36PM -0800, Steve Kargl wrote:
> > > On Mon, Feb 15, 2021 at 12:49:13PM -0800, Steve Kargl wrote:
> > > > On Sun, Feb 14, 2021 at 01:59:58PM -0800, Steve Kargl wrote:
> > > > > Just a headsup for anyone doing numerical work with
> > > > > FreeBSD-current.  clang with optimization of -O1 or
> > > > > higher produces wrong results.  Testing 1 million 
> > > > > complex values of ccoshf and limiting |z| < 20,
> > > > > shows
> > > > > 
> > > > 
> > > > This is either an in-ling bug or discarding a cast issue.
> > > > With everything in the same file so clang has dp_ccosh
> > > > available to it when compiling main.
> > > > 
> > > 
> > > Code builds and works as expected with gcc 10.2and
> > > gcc 11.0.0.
> > > 
> > 
> > Can't find a list of options that is equivalent to -O1,
> > so cannot test various optimizations.
> > 
> > Notice that -march=i686 gives the wrong results and
> > -march=core2 gives the correct result.  Trying -march=i686
> > -msse -msse2 gives the correct result.  It seems that
> > clang does not understand how the x87 (on i585-freebsd).
> 
> I tried looking around some and got the following
> that might be contributing: variations in
> __FLT_EVAL_METHOD__ used . . .
> 
> # cc -target i386-unknown-freebsd14.0 -march=i686 -O2 -x c /dev/null -dM -E | 
> egrep "(FLT_EVAL_METHOD|ILP32|LP64)"
> #define _ILP32 1
> #define __FLT_EVAL_METHOD__ 2
> #define __ILP32__ 1
> 
> # cc -target i386-unknown-freebsd14.0 -march=core2 -O2 -x c /dev/null -dM -E 
> | egrep "(FLT_EVAL_METHOD|ILP32|LP64)"
> #define _ILP32 1
> #define __FLT_EVAL_METHOD__ 0
> #define __ILP32__ 1
> 
> # cc -target x86_64-unknown-freebsd14.0 -march=core2 -O2 -x c /dev/null -dM 
> -E | egrep "(FLT_EVAL_METHOD|ILP32|LP64)"
> #define _LP64 1
> #define __FLT_EVAL_METHOD__ 0
> #define __LP64__ 1
> 
> FYI: It does not look like FreeBSD's /usr/include/x86/float.h
> matches all the detail:
> 
> #if __ISO_C_VISIBLE >= 1999
> #ifdef __LP64__
> #define FLT_EVAL_METHOD 0   /* no promotions */
> #else
> #define FLT_EVAL_METHOD (-1)/* i387 semantics are...interesting */
> #endif
> . . .
> #endif
> 
> 
> For reference:
> 
> # cc -target i386-unknown-freebsd14.0 -O2 -x c /dev/null -dM -E | egrep 
> "(FLT_EVAL_METHOD|ILP32|LP64)"
> #define _ILP32 1
> #define __FLT_EVAL_METHOD__ 2
> #define __ILP32__ 1
> 
> # cc -target x86_64-unknown-freebsd14.0 -O2 -x c /dev/null -dM -E | egrep 
> "(FLT_EVAL_METHOD|ILP32|LP64)"
> #define _LP64 1
> #define __FLT_EVAL_METHOD__ 0
> #define __LP64__ 1
> 
> # cc -target x86_64-unknown-freebsd14.0 -march=i686 -O2 -x c /dev/null -dM -E 
> | grep FLT_EVAL_METHOD | sort
> error: unknown target CPU 'i686'
> note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, 
> silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7, westmere, 
> sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, 
> broadwell, skylake, skylake-avx512, skx, cascadelake, cooperlake, cannonlake, 
> icelake-client, icelake-server, tigerlake, knl, knm, k8, athlon64, athlon-fx, 
> opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, 
> btver2, bdver1, bdver2, bdver3, bdver4, znver1, znver2, x86-64
> 
> # cc -v
> FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git 
> llvmorg-11.0.1-0-g43ff75f2c3fe)
> Target: x86_64-unknown-freebsd14.0
> Thread model: posix
> InstalledDir: /usr/bin
> 

Doesn't surprise me.  gcc knows about freebsd special handling of
the i387 on i686-*-freebsd.  clang does not.

clang:
% cc -E -dM -c -march=i686 testf.c | egrep "(FLT_EVAL_METHOD|__ILP32|__LP64)"
#define FLT_EVAL_METHOD (-1)
#define __FLT_EVAL_METHOD__ 2
#define __ILP32__ 1

gcc10:
% gcc10 -E -dM -c -march=i686 testf.c | egrep "(FLT_EVAL_METHOD|__ILP32|__LP64)"
#define __FLT_EVAL_METHOD__ 2
#define __FLT_EVAL_METHOD_TS_18661_3__ 2
#define __ILP32__ 1
#define FLT_EVAL_METHOD __FLT_EVAL_METHOD__

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADSUP: math is broken with clang and optimization

[Steve Kargl]

On Mon, Feb 15, 2021 at 01:03:36PM -0800, Steve Kargl wrote:
> On Mon, Feb 15, 2021 at 12:49:13PM -0800, Steve Kargl wrote:
> > On Sun, Feb 14, 2021 at 01:59:58PM -0800, Steve Kargl wrote:
> > > Just a headsup for anyone doing numerical work with
> > > FreeBSD-current.  clang with optimization of -O1 or
> > > higher produces wrong results.  Testing 1 million 
> > > complex values of ccoshf and limiting |z| < 20,
> > > shows
> > > 
> > 
> > This is either an in-ling bug or discarding a cast issue.
> > With everything in the same file so clang has dp_ccosh
> > available to it when compiling main.
> > 
> 
> Code builds and works as expected with gcc 10.2and
> gcc 11.0.0.
> 

Can't find a list of options that is equivalent to -O1,
so cannot test various optimizations.

Notice that -march=i686 gives the wrong results and
-march=core2 gives the correct result.  Trying -march=i686
-msse -msse2 gives the correct result.  It seems that
clang does not understand how the x87 (on i585-freebsd).

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADSUP: math is broken with clang and optimization

[Steve Kargl]

On Mon, Feb 15, 2021 at 12:49:13PM -0800, Steve Kargl wrote:
> On Sun, Feb 14, 2021 at 01:59:58PM -0800, Steve Kargl wrote:
> > Just a headsup for anyone doing numerical work with
> > FreeBSD-current.  clang with optimization of -O1 or
> > higher produces wrong results.  Testing 1 million 
> > complex values of ccoshf and limiting |z| < 20,
> > shows
> > 
> 
> This is either an in-ling bug or discarding a cast issue.
> With everything in the same file so clang has dp_ccosh
> available to it when compiling main.
> 

Code builds and works as expected with gcc 10.2and
gcc 11.0.0.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADSUP: math is broken with clang and optimization

[Steve Kargl]

On Sun, Feb 14, 2021 at 01:59:58PM -0800, Steve Kargl wrote:
> Just a headsup for anyone doing numerical work with
> FreeBSD-current.  clang with optimization of -O1 or
> higher produces wrong results.  Testing 1 million 
> complex values of ccoshf and limiting |z| < 20,
> shows
> 

This is either an in-ling bug or discarding a cast issue.
With everything in the same file so clang has dp_ccosh
available to it when compiling main.

void
dp_ccosh(double x, double y, double *re, double *im)
{
*re = cosh(x) * cos(y);
*im = sinh(x) * sin(y);
}

int
main(int argc, char *argv[])
{
   float complex f, z;
   double re, im, ur, ui;
   float x, y;
   float xmax;
...
   for (j = 0; j < NUM; j++) {

   x = xmax * rangef();
   y = xmax * rangef();
   z = CMPLXF(x,y);
   f = ccoshf(z);

   dp_ccosh((double)x, (double)y, &re, &im);


gives the wrong results.  Changing this to

int
main(int argc, char *argv[])
{
   float complex f, z;
   double re, im, ur, ui;
   float x, y;
   volatile float xv, yv;
   float xmax;
...
   for (j = 0; j < NUM; j++) {

   xv = x = xmax * rangef();
   yv = y = xmax * rangef();
   z = CMPLXF(x,y);
   f = ccoshf(z);

   dp_ccosh((double)xv, (double)yv, &re, &im);

gives the expected and correct results.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

HEADSUP: math is broken with clang and optimization

[Steve Kargl]

Just a headsup for anyone doing numerical work with
FreeBSD-current.  clang with optimization of -O1 or
higher produces wrong results.  Testing 1 million 
complex values of ccoshf and limiting |z| < 20,
shows

% cc -o testf -O2 -pipe -static -Wall -fno-builtin \
  -I/usr/home/kargl/include -I/usr/local/include -I../mp \
  -I../libm/msun/src testf.c  -L/usr/home/kargl/lib \
  -L/usr/local/lib -L../mp -L../libm/msun -lmpsk -lmpfr -lgmp -lm
% ./testf -u -n 1 -X 10
Max ULP Re: 136633.320045
Max ULP Im: 1890038.672637

% cc -o testf -O0 -pipe -static -Wall -fno-builtin \
  -I/usr/home/kargl/include -I/usr/local/include -I../mp \
  -I../libm/msun/src testf.c  -L/usr/home/kargl/lib \
  -L/usr/local/lib -L../mp -L../libm/msun -lmpsk -lmpfr -lgmp -lm
% ./testf -u -n 1 -X 10
Max ULP Re: 2.785010
Max ULP Im: 2.926068

One of these is more correct than the other.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PACTH,libm] hypothl(x) mishandles subnormal numbers.

[Steve Kargl]

On Wed, Feb 10, 2021 at 12:26:29AM +0100, Dimitry Andric wrote:
> 
> > On 10 Feb 2021, at 00:15, Steve Kargl  
> > wrote:
> > 
> > This patch fixes the issue.  t1 is used to scale the subnormal
> > numbers.  It is generated by scaling the exponent, but that
> > only works if t1 is 1 not 0.
> > 
> > Index: src/e_hypotl.c
> > ===
> > --- src/e_hypotl.c  (revision 2342)
> > +++ src/e_hypotl.c  (working copy)
> > @@ -82,7 +82,7 @@ hypotl(long double x, long double y)
> > man_t manh, manl;
> > GET_LDBL_MAN(manh,manl,b);
> > if((manh|manl)==0) return a;
> > -   t1=0;
> > +   t1=1;
> > SET_HIGH_WORD(t1,ESW(MAX_EXP-2));   /* t1=2^(MAX_EXP-2) */
> > b *= t1;
> > a *= t1;
> > 
> 
> Ah, having looked at the glibc code, I had concluded something similar
> in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253313#c2, but
> using INSERT_LDBL80_WORDS(t1,ESW(MAX_EXP-2),0x8000).
> 
> Your solution is a lot simpler though. :) Note that to make it work, I
> also needed to insert a volatile into the INSERT_LDBL80_WORDS() macro.

I don't look at glibc's libm code due to possible Copyright
issues (long/short story that I rather not get into here).
I do, however, have a math_sgk.h that appears at the
end of math_privated.h with a bunch of instrumentation code
hidden behind -DEBUG.  For the above, it becomes

t1=0;
SET_HIGH_WORD(t1,ESW(MAX_EXP-2));   /* t1=2^(MAX_EXP-2) */
PRNL(t1);

which yields inf as output.  Clearly, not a scaling of a subnormal
to a normal number.


> There are more places where this is apparently needed, due to the way
> recent clang versions tend to over-optimize floating point code at
> compile time. And specifically for the case where one union field is
> written, and then another field read, sometimes leading to unexpected
> results...

Hmmm.  This is a bummer.  I suppose someone will say the code
in msun is using undefined behavior or some such standardese.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[PACTH,libm] hypothl(x) mishandles subnormal numbers.

[Steve Kargl]

On Sat, Feb 06, 2021 at 10:32:33PM +0100, Dimitry Andric wrote:
> On 6 Feb 2021, at 22:04, Steve Kargl  
> wrote:
> > 
> > On Sat, Feb 06, 2021 at 12:39:29PM -0800, Steve Kargl wrote:
> >> I've long forgotten by freebsd bugzilla password.
> >> So, if someone would like to submit a bug report,
> >> here's a test program.
> >> 
> > Forgot to include that issue was identified from
> > a bug report in the OpenLibm bug mailing list.
> > 
> > https://github.com/JuliaMath/openlibm/issues/224
> 
> I put this in <https://bugs.freebsd.org/253313>. Now the trick is to
> figure out what is going on in e_hypotl.c... :)
> 

This patch fixes the issue.  t1 is used to scale the subnormal
numbers.  It is generated by scaling the exponent, but that 
only works if t1 is 1 not 0.

Index: src/e_hypotl.c
===
--- src/e_hypotl.c  (revision 2342)
+++ src/e_hypotl.c  (working copy)
@@ -82,7 +82,7 @@ hypotl(long double x, long double y)
man_t manh, manl;
GET_LDBL_MAN(manh,manl,b);
if((manh|manl)==0) return a;
-   t1=0;
+   t1=1;
SET_HIGH_WORD(t1,ESW(MAX_EXP-2));   /* t1=2^(MAX_EXP-2) */
b *= t1;
a *= t1;


-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: any images for freebsd-current?

[Steve Kargl]

On Mon, Feb 08, 2021 at 03:03:10AM +, Glen Barber wrote:
> On Sat, Feb 06, 2021 at 11:59:27AM -0800, Steve Kargl wrote:
> > Any one aware of where images from freebsd-current?
> > freebsd.org appears to offer no images.
> > 
> 
> Some juggling needs to be done to the release build machines, which
> I hope to have done this week before the weekly snapshots.
> 

Glen (and Warner),

After poking around on freebsd.org, I concluded Release
Engineers were busy with 13.0 and 14.0 would come along.
Fortunately, wo people have sent private emails to images
that they had created.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[PATCH, LIBM] powf is wrong with x near 1 and |y| >> 1

[Steve Kargl]

See the last few comments here:

https://github.com/JuliaMath/openlibm/issues/211

Test program:

#include 
#include 
  
#if defined(__i386__)
#include 
#endif

int main()
{
  float x, y, z, a;
#if defined(__i386__)
fpsetprec(FP_PE);
#endif
  x = 0x1.eep-1f;
  y = -0x1.02p+27f;
  z = powf (x, y);
  printf ("x=%e y=%e z=%e\n", x, y, z);
  printf ("x=%a y=%a z=%a\n", x, y, z);

  a = expf(y * logf(x)); // 0x1.d53532p+103f;
  printf ("floats: a=%a a=%e\n", a, a);
  a = (float)exp(y * log(x)); // 0x1.d53532p+103f;
  printf (" dbles: a=%a a=%e\n", a, a);
  return 0;
}

Patch without too much analysis for x near 1 or |y| > 2**27.

Index: src/e_powf.c
===
--- src/e_powf.c(revision 2342)
+++ src/e_powf.c(working copy)
@@ -136,7 +136,7 @@ __ieee754_powf(float x, float y)
 /* |y| is huge */
if(iy>0x4d00) { /* if |y| > 2**27 */
/* over/underflow if x is not close to one */
-   if(ix<0x3f78) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
+   if(ix<0x3f77) return (hy<0)? sn*huge*huge:sn*tiny*tiny;
if(ix>0x3f87) return (hy>0)? sn*huge*huge:sn*tiny*tiny;
/* now |1-x| is tiny <= 2**-20, suffice to compute
   log(x) by x-x^2/2+x^3/3-x^4/4 */

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: hypothl(x) mishandles subnormal numbers.

[Steve Kargl]

On Sat, Feb 06, 2021 at 10:32:33PM +0100, Dimitry Andric wrote:
> On 6 Feb 2021, at 22:04, Steve Kargl  
> wrote:
> > 
> > On Sat, Feb 06, 2021 at 12:39:29PM -0800, Steve Kargl wrote:
> >> I've long forgotten by freebsd bugzilla password.
> >> So, if someone would like to submit a bug report,
> >> here's a test program.
> >> 
> > Forgot to include that issue was identified from
> > a bug report in the OpenLibm bug mailing list.
> > 
> > https://github.com/JuliaMath/openlibm/issues/224
> 
> I put this in <https://bugs.freebsd.org/253313>. Now the trick is to
> figure out what is going on in e_hypotl.c... :)
> 

Thanks.  I took a quick look, and there seems to
be some magic scaling happen.  hypotl(x,y) should
compute sqrtl(x*x+y*y) while avoiding overflows
and underflows.  I suspect that the scaling needs
to be tweaked.  It may take me a bit to work out
how to fix it.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: any images for freebsd-current?

[Steve Kargl]

On Sat, Feb 06, 2021 at 04:49:46PM -0500, Dennis Clarke via freebsd-current 
wrote:
> On 2/6/21 4:02 PM, Steve Kargl wrote:
> > On Sat, Feb 06, 2021 at 03:33:48PM -0500, Dennis Clarke via freebsd-current 
> > wrote:
> >> On 2/6/21 2:59 PM, Steve Kargl wrote:
> >>> Any one aware of where images from freebsd-current?
> >>> freebsd.org appears to offer no images.
> >>>
> >>
> >> try
> >> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/
> >>
> >> Also .. have you tried RISC-V ??
> >>
> > 
> > 13.0 does not equal 14.0.  On my Dell Latitude D530 laptop,
> > i386-freebsd current ran well up to about Dec 2, 2020.  Since
> > an attempted update in early Jan 2021, I've had nothing but
> > daily panics and other issues.  There are two possibilities:
> > (1) failing hardware and/or (2) recently introduced i386-freebsd
> > kernel issues.  Installing amd64-freebsd may eliminate one
> > of the two possibilities.
> > 
> 
> so install the latest there and then do a buildworld and buildkernel.
> 
> easy.

Ah, that's my question.  Where can I find a freebsd-14.0 
amd64 iso image so that I can install the latest?

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: any images for freebsd-current?

[Steve Kargl]

On Sat, Feb 06, 2021 at 03:33:48PM -0500, Dennis Clarke via freebsd-current 
wrote:
> On 2/6/21 2:59 PM, Steve Kargl wrote:
> > Any one aware of where images from freebsd-current?
> > freebsd.org appears to offer no images.
> > 
> 
> try
> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/
> 
> Also .. have you tried RISC-V ??
> 

13.0 does not equal 14.0.  On my Dell Latitude D530 laptop,
i386-freebsd current ran well up to about Dec 2, 2020.  Since
an attempted update in early Jan 2021, I've had nothing but
daily panics and other issues.  There are two possibilities:
(1) failing hardware and/or (2) recently introduced i386-freebsd
kernel issues.  Installing amd64-freebsd may eliminate one
of the two possibilities.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: hypothl(x) mishandles subnormal numbers.

[Steve Kargl]

On Sat, Feb 06, 2021 at 12:39:29PM -0800, Steve Kargl wrote:
> I've long forgotten by freebsd bugzilla password.  
> So, if someone would like to submit a bug report,
> here's a test program.
> 
Forgot to include that issue was identified from
a bug report in the OpenLibm bug mailing list.

https://github.com/JuliaMath/openlibm/issues/224

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

hypothl(x) mishandles subnormal numbers.

[Steve Kargl]

I've long forgotten by freebsd bugzilla password.  
So, if someone would like to submit a bug report,
here's a test program.

% cc -o z -O2 -fno-builtin z.c -lm
% ./z
Via scaling and sqrtl
x=2.853684e-4932 y=1.444012e-4922 a=1.444012e-4922
x=0x1.b2933cafa0bb8p-16383 y=0x1.fp-16351 
a=0x1.6ca4c8p-16350

Via hypotl
x=2.853684e-4932 y=1.444012e-4922 z=nan
x=0x1.b2933cafa0bb8p-16383 y=0x1.fp-16351 z=nan

% cat z.c
#include 
#include 

#if defined(__i386__)
#include 
#endif

int main()
{
  long double x, y, z, a;

#if defined(__i386__)
fpsetprec(FP_PE);
#endif

   x = 0x3.6526795f4176ep-16384L;
   y = 0x3.ep-16352L;
   z = hypotl(x, y);

   if (x > y) {
  a = y / x;
  a = x * sqrtl(1 + a);
   } else {
  a = x / y;
  a = y * sqrtl(a + 1);
   }

   printf("Via scaling and sqrtl\n");
   printf("x=%Le y=%Le a=%Le\n", x, y, a);
   printf("x=%La y=%La a=%La\n", x, y, a);

   printf("\nVia hypotl\n");
   printf("x=%Le y=%Le z=%Le\n", x, y, z);
   printf("x=%La y=%La z=%La\n", x, y, z);

   return 0;
}

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"