https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #77 from commit-h...@freebsd.org ---
A commit in branch stable/14 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=f9857ea43a38b74e34ce7f6576ad4e6415413454
commit f9857ea43a38b74e34ce7f6576ad4e6415413454
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #76 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=0698ce429f78f548f7eb3e54476fb312109ddd8b
commit 0698ce429f78f548f7eb3e54476fb312109ddd8b
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #75 from Koichiro Iwao ---
(In reply to Konstantin Belousov from comment #74)
Yes, no issues as far as I tested.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #74 from Konstantin Belousov ---
(In reply to Koichiro Iwao from comment #73)
Yes, this is normal. We do not aim to report the host values, only something
that makes the guest accept the values.
So no other issues?
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #73 from Koichiro Iwao ---
(In reply to Konstantin Belousov from comment #72)
> In what sense this is wrong?
> 32MB is relatively reasonable number. What misbehavior do you see?
The processor actually has only 16MB L3 cache bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #72 from Konstantin Belousov ---
(In reply to Koichiro Iwao from comment #71)
In what sense this is wrong?
x86.cpu_features.level3_cache_size=0x200 # 33554432 -> 32MiB <= WRONG!
32MB is relatively reasonable number. What
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #71 from Koichiro Iwao ---
(In reply to Mark Peek from comment #69)
With your patch, EL8 glibc no longer crashes. It looks good to me as for this
issue. However, it still reports wrong L3 cache size.
My processor is AMD Ryzen 7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #70 from Konstantin Belousov ---
(In reply to Mark Peek from comment #69)
Thank you for the analysis. I realized that it is just a bug in the patch.
The intent was to set the number of cache ways to 1, but I ignored the 'number
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #69 from Mark Peek ---
Having just received an AMD 7840U I wanted to do a little more research into
this bug and the current patch. Given the cache values I am seeing I believe
the patch needs a small change.
Looking at the cac
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #68 from Koichiro Iwao ---
(In reply to Koichiro Iwao from comment #65)
This wasn't correct.
> The bhyve patch means here is the following:
>
>--- a/sys/amd64/vmm/x86.c
>+++ b/sys/amd64/vmm/x86.c
>@@ -152,6 +152,8 @@ x86_emula
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #67 from Koichiro Iwao ---
(In reply to Adhemerval Zanella from comment #66)
> If I understand correctly, both AlmaLinux 9.5 and Kitten 10 works correctly
> now after glibc upstream fixed the issue and it was backported, right?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #66 from Adhemerval Zanella ---
(In reply to Koichiro Iwao from comment #65)
> - Fix EL8 glibc issue in upstream if it is an upstream issue
If I understand correctly, both AlmaLinux 9.5 and Kitten 10 works correctly now
after
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #65 from Koichiro Iwao ---
(In reply to Florian Weimer from comment #63)
Let me sort out the remaining issues.
1TB L3 cache issue:
- Addressed in glibc upstream
- AlmaLinux 9.5 and Kitten 10 already include the upstream pat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #64 from Konstantin Belousov ---
(In reply to Florian Weimer from comment #63)
I believe that the Alma issue is different. It is only for the patched bhyve.
It is probably something that the old glibc wants from CPUID.
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #63 from Florian Weimer ---
(In reply to Konstantin Belousov from comment #62)
The command used was:
> podman run -it --rm quay.io/almalinuxorg/almalinux:8 /bin/bash
This is not going to work until the container image is upda
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #62 from Konstantin Belousov ---
(In reply to Adhemerval Zanella from comment #61)
Somebody needs to help debug the Alma Linux crash report for the supposed fix.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #61 from Adhemerval Zanella ---
It has been fixed on glibc [1], although it seems that bhyve still sets the L3
cache size to bogus value (which might impact in perfomance, since it
influences in which string optimization will be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #60 from Darren Henderson ---
Giving this a bump... haven't seen any movement for a while now. This strikes
me as being pretty critical.
It is now possible to upgrade from Almalinux 9.4 to 9.5 - I gather they
reverted the lib c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #59 from Koichiro Iwao ---
(In reply to Konstantin Belousov from comment #57)
I re-added the width stuff didn't help.
$ podman run -it --rm quay.io/almalinuxorg/almalinux:8 /bin/bash
[ 16.234882] bash[1001]: segfault at 7ffd8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #58 from Koichiro Iwao ---
(In reply to Konstantin Belousov from comment #57
)I'm not familiar with this low-layer area, so I need to know how to
disassemble. Anyway, I'll try reverting the width stuff first.
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #57 from Konstantin Belousov ---
(In reply to Konstantin Belousov from comment #56)
Also, as a blind guess, try to revert this chunk
- if (width < 0x4)
- width
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #56 from Konstantin Belousov ---
(In reply to Koichiro Iwao from comment #55)
So can you disassemble the function around the faulted address from libc.so,
please?
--
You are receiving this mail because:
You are the assignee fo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #55 from Koichiro Iwao ---
Created attachment 256146
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256146&action=edit
almalinux-8-patched-bhyve-ldso-list-diagnostics.txt
Just in case it might be useful, I attach the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #54 from Koichiro Iwao ---
(In reply to Koichiro Iwao from comment #53)
> Host: FreeBSD 14-STABLE w/ patch comment #14 on AMD Ryzen 7 5700G
I meant comment #41 here.
--
You are receiving this mail because:
You are the assigne
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #53 from Koichiro Iwao ---
The bhyve patch in comment #41 broke EL8 (AlmaLinux 8, RockyLinux 8). There was
no issue with unpatched bhyve.
Host: FreeBSD 14-STABLE w/ patch comment #14 on AMD Ryzen 7 5700G
Guest: AlmaLinux 8.10,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #52 from Koichiro Iwao ---
Just for the record:
- https://issues.redhat.com/browse/RHEL-71581
- https://issues.redhat.com/browse/RHEL-71583
- https://issues.redhat.com/browse/RHEL-71584
--
You are receiving this mail because:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #51 from Konstantin Belousov ---
https://reviews.freebsd.org/D48187
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #50 from Koichiro Iwao ---
(In reply to Konstantin Belousov from comment #49)
Yes, unpatched glibc with patched bhyve works. After unpatching bhyve, it
causes segfault again.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #49 from Konstantin Belousov ---
(In reply to Koichiro Iwao from comment #48)
Ok, but does unpatched glibc work on patched bhyve?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #48 from Koichiro Iwao ---
(In reply to Konstantin Belousov from comment #44)
Sorry, it turned out that I could not apply your patch provided in comment #41.
I believe the patch is properly applied now. Now it looks to be workin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #47 from Koichiro Iwao ---
Created attachment 256096
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256096&action=edit
x86info-r-patched-bhyve-14-stable.txt
--
You are receiving this mail because:
You are the assign
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #46 from Koichiro Iwao ---
Created attachment 256095
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256095&action=edit
x86info-r-vanilla-bhyve-14-1-release.txt
--
You are receiving this mail because:
You are the ass
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #45 from Koichiro Iwao ---
(In reply to Florian Weimer from comment #43)
glibc I use here is not an updated version.
The updated glibc is working fine, and I backported your patch to AlmaLinux
9.5. The updated package will be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #44 from Konstantin Belousov ---
(In reply to Florian Weimer from comment #43)
I am sure it is with the previous (not fixed) glibc and my bhyve patch applied.
(In reply to Koichiro Iwao from comment #42)
Could you please show t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #43 from Florian Weimer ---
(In reply to Koichiro Iwao from comment #42)
> I still get the same result.
With an updated glibc? Which version did you build, and how did you install it?
--
You are receiving this mail because:
Y
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #42 from Koichiro Iwao ---
(In reply to Konstantin Belousov from comment #41)
I still get the same result.
$ ld.so --list-diagnostics |grep cache
x86.cpu_features.data_cache_size=0x8000
x86.cpu_features.shared_cache_size=0x1000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #41 from Konstantin Belousov ---
(In reply to Florian Weimer from comment #39)
For 8000_001Dh, the %ecx == 0 reply seems to be legal, for fully assoc cache.
This probably explains why my previous attempt did not worked, lets arb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #40 from Michael Dexter ---
(In reply to Koichiro Iwao from comment #34)
That was relayed from a colleague and I am awaiting a link. :-|
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #39 from Florian Weimer ---
(In reply to Konstantin Belousov from comment #37)
> Do you see which CPUID leaf causes the trouble?
Let me try based on attachment 255708. The maximum leaf is 0x8023 according
to this:
x86.proc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #38 from Koichiro Iwao ---
(In reply to Konstantin Belousov from comment #37)
This didn't help. It still reports the same l3 cache size.
$ ld.so --list-diagnostics |grep cache
x86.cpu_features.data_cache_size=0x8000
x86.cpu_fea
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #37 from Konstantin Belousov ---
(In reply to Florian Weimer from comment #36)
Do you see which CPUID leaf causes the trouble?
As a guess, I wonder if the following bhyve patch helps (it tries to fix
CPUID leaf 0x8000_001D %ecx
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #36 from Florian Weimer ---
Thanks for the offers of machine access.
I should have studied the ld.so --list-diagnostics output. It's a recurrence of
the previous rep_movsb_threshold bug because it ends up as zero. The bhyve bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #35 from Koichiro Iwao ---
(In reply to Florian Weimer from comment #33)
I can provide you access to the system if you're IPv6 reachable. Could you
email me the public SSH key?
--
You are receiving this mail because:
You are t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #34 from Koichiro Iwao ---
(In reply to Konstantin Belousov from comment #32)
> This is reportedly fixed in Alma Linux.
I don't get exactly Michael Dexter meant but this is a misunderstanding. I,
with a hat of AlmaLinux develop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #33 from Florian Weimer ---
If someone can provide me SSH access to a guest system that exhibits the issue
once glibc is updated, I can try to debug it (assuming that GDB/ptrace works on
the guest, but I don't see why it wouldn'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #32 from Konstantin Belousov ---
(In reply to Michael Dexter from comment #31)
Can you provide any details on the supposed fix?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
Michael Dexter changed:
What|Removed |Added
CC||edi...@callfortesting.org
--- Com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #30 from Konstantin Belousov ---
I do believe that the problem is specific to AMD. The AMD hw virtualization
assist (SVM) is completely different from the Intel facility (VMX), and perhaps
there is a bug in bhyve.
What is not
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
Mark Peek changed:
What|Removed |Added
CC||m...@freebsd.org
--- Comment #29 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #28 from Darren Henderson ---
This has been sitting unassigned for nearly six months now apparently - can we
up the priority and scope of effected systems?
It is present in 14.2 as well as 14.1 and is going to become more criti
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #27 from Koichiro Iwao ---
(In reply to Darren Henderson from comment #26)
Yes, RHEL derivatives 9.5 includes this patch to glibc and it is an issue:
https://gitlab.com/redhat/centos-stream/rpms/glibc/-/commit/6dbf26d6f46fce37e6
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
Darren Henderson changed:
What|Removed |Added
CC||darren.hender...@gmail.com
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #25 from Florian Weimer ---
(In reply to Getz Mikalsen from comment #24)
I can confirm that the data looks complete now, thnaks. Now I just have to find
someone who can make sense of it. 8-)
--
You are receiving this mail bec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
Getz Mikalsen changed:
What|Removed |Added
Attachment #255691|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #23 from Florian Weimer ---
(In reply to Getz Mikalsen from comment #22)
> It's /usr/bin/ld.so from glibc 2.40 copied over into an older distribution
> running 2.36 just like you asked.
Sorry, It looks like you have copied ove
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #22 from Getz Mikalsen ---
(In reply to Florian Weimer from comment #21)
It's /usr/bin/ld.so from glibc 2.40 copied over into an older distribution
running 2.36 just like you asked.
I was able to install the latest archlinux is
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #21 from Florian Weimer ---
(In reply to Getz Mikalsen from comment #20)
> ld.so --list-diagnostics from glibc240
Sorry, this says “version.version="2.36"” in the dump, and it lacks the CPUID
diagnostics.
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #20 from Getz Mikalsen ---
Created attachment 255691
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=255691&action=edit
ld.so --list-diagnostics from glibc240
--
You are receiving this mail because:
You are the assig
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
Adhemerval Zanella changed:
What|Removed |Added
CC||zatr...@gmail.com
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
Florian Weimer changed:
What|Removed |Added
CC||fwei...@redhat.com
--- Comment #1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
Getz Mikalsen changed:
What|Removed |Added
CC||g...@dflund.se
--- Comment #17 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #16 from Evgenii Khramtsov <2khramt...@gmail.com> ---
Not exposing ERMS in CPUID works fine here as a workaround with Arch Linux@Zen
3:
diff --git a/sys/amd64/vmm/x86.c b/sys/amd64/vmm/x86.c
--- a/sys/amd64/vmm/x86.c
+++ b/sys/a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
Koichiro Iwao changed:
What|Removed |Added
CC||m...@freebsd.org
UR
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
Evgenii Khramtsov <2khramt...@gmail.com> changed:
What|Removed |Added
CC||2khramt..
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #13 from bugzi...@tunedal.net ---
(In reply to Konstantin Belousov from comment #12)
Here are the register values you asked for. Installing the debug symbols using
debuginfod (or find-dbgsym-packages) doesn't seem to have change
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #12 from Konstantin Belousov ---
Just in case, could you also please show the GPR file ((gdb) show registers).
>From what you posted, the damage was done elsewhere and it is an innocent
general purpose instruction that got inva
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
bugzi...@tunedal.net changed:
What|Removed |Added
CC||bugzi...@tunedal.net
--- Com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #10 from Konstantin Belousov ---
Perhaps LD_LIBRARY_PATH to force the crashing binary to use crashing libc is
the easiest.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #9 from Kyle Evans ---
(In reply to Konstantin Belousov from comment #8)
One could `add-symbol-file` in a saved off copy of the broken shlib at the
expected offset and get expected disassembly, perhaps? Not as easy as written
b
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #8 from Konstantin Belousov ---
(In reply to Kyle Evans from comment #7)
Most likely noit, unfortunately. The downgrade of libc would cause wrong code
to be disassembled, because text is not dumped normally.
Is there a way to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #7 from Kyle Evans ---
(In reply to jordy from comment #3)
> It's kind of difficult to debug as gdb will also crash when the latest glibc
> is installed. The other user of the arch forum made some backtraces of some
> applica
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #6 from Raúl ---
I see on that sid dmesg:
[173364.415802] apt[5234]: segfault at 7f29a9d1aff8 ip 7f29aa36ff25 sp
7ffcc0b4ad18 error 4 in libc.so.6[7f29aa23f000+158000] likely on CPU 3
(core 0, socket 3)
[173364.415815]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #5 from Raúl ---
CPU: AMD Ryzen 9 5950X 16-Core Processor (3393.72-MHz K8-class CPU)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
Raúl changed:
What|Removed |Added
CC||raul.mu...@custos.es
--- Comment #4 from Ra
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
--- Comment #3 from jo...@jvwdev.nl ---
How can I help to debug this? On my arch vm I still downgrade glibc, which only
works for so long on a rolling release. I tried to install Fedora Server 40
(netinstall) which also fails during installa
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
Konstantin Belousov changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
tennix changed:
What|Removed |Added
CC||zten...@gmail.com
--- Comment #1 from ten
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279901
Bug ID: 279901
Summary: glibc-2.39-2 and above on the host segfault
Product: Base System
Version: 14.1-RELEASE
Hardware: amd64
OS: Any
Status: New
S
78 matches
Mail list logo
