https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277389
--- Comment #32 from Mark Millard ---
(In reply to Mark Millard from comment #31)
The console output's backtrace:
panic: pmap_growkernel: no memory to grow kernel
cpuid = 6
time = 1710740968
KDB: stack backtrace:
db_trace_self() at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277389
--- Comment #34 from Mark Millard ---
FYI:
With vfs.nullfs.cache_vnodes=0 I instead got the
"failed to reclaim memory" type of failure, losing
control because of what had been killed.
So the nullfs VNODE caching is not a fundamental
part
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277389
--- Comment #30 from Mark Millard ---
The dump worked. The backtrace related part of core.txt.0
follows. The system was booted from a PkgBase kernel and
world for the test, not from a personal build.
# less /var/crash/core.txt.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277389
--- Comment #33 from Mark Millard ---
(In reply to Mark Millard from comment #32)
FYI:
This is still with the very simple zpool type: a
single GPT partition on just one physical drive.
No other zpool present.
The drive was attached via
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277389
--- Comment #35 from Mark Millard ---
(In reply to Mark Millard from comment #33)
Going in a different direction: I set up 118 GiBytes of
swap (so: RAM+SWAP=150 GiBytes).
It made little difference, things apparently being
killed. (No OOM
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277389
--- Comment #31 from Mark Millard ---
(In reply to Mark Millard from comment #30)
The vmstat -z output:
vmstat -z
ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP XDOM
UMA Kegs: 512, 0,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272260
Dag-Erling Smørgrav changed:
What|Removed |Added
Flags|maintainer-feedback?(doc@Fr |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276102
--- Comment #4 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=59b02bb420e3b0a49af39f7817764ca444f7c793
commit 59b02bb420e3b0a49af39f7817764ca444f7c793
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277764
Konstantin Belousov changed:
What|Removed |Added
CC||k...@freebsd.org
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277699
--- Comment #1 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=85c3ef77cc9f7dbf8500c3d16c82d24eb06bfa81
commit 85c3ef77cc9f7dbf8500c3d16c82d24eb06bfa81
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272260
Dag-Erling Smørgrav changed:
What|Removed |Added
CC||d...@freebsd.org
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277783
Bug ID: 277783
Summary: libc fma() doesn't not return the correct zero sign
Product: Base System
Version: 14.0-RELEASE
Hardware: Any
OS: Any
Status: New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277717
--- Comment #6 from Paolo Tealdi ---
I installed the patch provided by Seigo Tanimura on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275594 and the bug that
affected another of my server with 13.3-RELEASE seems to be disappeared.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274536
--- Comment #12 from Edward Tomasz Napierala ---
Sorry, no joy - with those two applied it still panics like before, with
similar backtrace.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274536
--- Comment #13 from Gleb Smirnoff ---
On Mon Mar 18 16:56:14 2024 UTC, tr...@freebsd.org wrote:
> Sorry, no joy - with those two applied it still panics like before, with
> similar
> backtrace.
I have just updated both revisions and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277783
--- Comment #2 from Steve Kargl ---
So, I don't loose a reduced version of the code:
#include
#include
int
main(void)
{
volatile double x = 0x1p-500, y = 0x1p-550, z = 0x1p-1000;
double a, b, c, r;
a = x-y;
b = x+y;
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277783
--- Comment #3 from Steve Kargl ---
If one looks in src/s_fma.c, one sees
#ifdef USE_BUILTIN_FMA
double
fma(double x, double y, double z)
{
return (__builtin_fma(x, y, z));
}
#else
If libm is built with -DUSE_BUILTIN_FMA, then
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277655
--- Comment #8 from Henrich Hartzer ---
I see, thank you! I drafted up a quick patch for sys/netinet/cc/. It's untested
and I don't understand all of the implications of the changes.
If it's worth reviewing, where should I submit it?
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=21
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277655
--- Comment #2 from Henrich Hartzer ---
Hi Ed,
It's in man section 9 for random.
https://man.freebsd.org/cgi/man.cgi?query=random=0=9=FreeBSD+14.0-RELEASE+and+Ports=default=html
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277655
--- Comment #7 from Henrich Hartzer ---
Created attachment 249283
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249283=edit
sys/netinet/cc switch from random() to prng32()
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277655
--- Comment #5 from Henrich Hartzer ---
Thank you! Is there another issue tracking what consumers still exist?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277655
--- Comment #6 from Ed Maste ---
There is no other issue for tracking that I'm aware of.
A grep turns up instances in:
sys/contrib/libsodium/src/libsodium/randombytes/randombytes.c
sys/contrib/openzfs/tests/zfs-tests/cmd/btree_test.c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277783
--- Comment #6 from Steve Kargl ---
(In reply to Steve Kargl from comment #4)
A similar issue is present in src/s_fmal.c. The patch in comment #4 can be
adapted for fmal.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277783
Ed Maste changed:
What|Removed |Added
CC||ema...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277655
--- Comment #4 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=f50322c1dcfe369ad73e1123541d18fc431384f6
commit f50322c1dcfe369ad73e1123541d18fc431384f6
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277783
--- Comment #4 from Steve Kargl ---
Ok, with the given input to fma, one arrives at line 271
return (xy.hi + vzs + ldexp(xy.lo, spread));
(gdb) p vzs
$12 = -0.5
(gdb) p xy.hi
$13 = 0.5
(gdb) p xy.lo
$14 =
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277655
--- Comment #3 from Ed Maste ---
oh, random(9), not random(3)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277794
Bug ID: 277794
Summary: llvm-objdump can reach llvm_unreachable("no symbol
table pointer!"), causing later trouble
Product: Base System
Version: CURRENT
Hardware:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277783
--- Comment #5 from Victor Stinner ---
Ed:
> Thank you for the report and C reproduction case. Do you know which other
> implementations are being tested? (macOS, musl, bionic?)
Python test_math checks fma() on Windows, Linux, macOS,
30 matches
Mail list logo
