[Bug 283276] FreeBSD 13.x and FreeBSD 14.x 32bit fail during install on Intel Sapphire Rapids
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 283276] FreeBSD 13.x and FreeBSD 14.x 32bit fail during install on Intel Sapphire Rapids"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 283276] FreeBSD 13.x and FreeBSD 14.x 32bit fail during install on Intel Sapphire Rapids"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 283276] FreeBSD 13.x and FreeBSD 14.x 32bit fail during install on Intel Sapphire Rapids"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 283276] FreeBSD 13.x and FreeBSD 14.x 32bit fail during install on Intel Sapphire Rapids"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 283276] FreeBSD 13.x and FreeBSD 14.x 32bit fail during install on Intel Sapphire Rapids"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 12 Dec 2024 04:02:46 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283276
Bug ID: 283276
Summary: FreeBSD 13.x and FreeBSD 14.x 32bit fail during
install on Intel Sapphire Rapids
Product: Base System
Version: 14.2-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: standards
Assignee: standards@FreeBSD.org
Reporter: yanhui.he@broadcom.com
Created attachment 255793
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=255793&action=edit
FreeBSD 14.2 32bit keep booting UI
FreeBSD 14.2 32bit keep booting after finish installation and reboot, not only
for FreeBSD 14.2 32bit VM on vSphere but on Physical machine with Intel
Sapphire Rapids. It's not a specific problem for FreeBSD 14.2 32bit VM but for
a real FreeBSD 14.2 32bit OS on a physical machine.
Please refer to the attached screenshot of "FreeBSD 14.2 32bit keep booting
UI.png".
We also tested FreeBSD 13.4 32bit, FreeBSD 14.0&14.1 32bit, hit the same issue.
We found it will happen with CPU based on Intel Sapphire Rapids.
Intel(R) Xeon(R) Gold 6448Y -----> SPR
The below is some debug information from the developer in our side on FreeBSD
14.2 32bit based on an Intel Sapphire Rapids.
******************
Did a bit more digging with FreeBSD ddb looking at the spot where things blow
up.
Built the kernel with no optimization, so generated assembly is trivial to
follow.
Breakpoint at sendsig+0x39a: movl %ecx,%esp
db> x/i sendsig+0x38d,8
x/i sendsig+0x38d,8
sendsig+0x38d: addl $-0x1fd,%eax
sendsig+0x392: andl $-0x4,%eax
sendsig+0x395: subl %eax,%ecx
sendsig+0x397: andl $-0x10,%ecx
sendsig+0x39a: movl %ecx,%esp <========== there
sendsig+0x39c: jmp sendsig+0x4d3
sendsig+0x3a1: movl 0xc(%ebp),%ecx
sendsig+0x3a4: movl 0x10(%ecx),%eax
db> p $ecx
p $ecx
cccc620 <========== stack to be
db> x cpu_max_ext_state_size
x cpu_max_ext_state_size
cpu_max_ext_state_size: 2b00
db> show thread
show thread
Thread 100087 at 0x1cc573c0:
proc (pid 654): 0x1cd776c8
name: syslogd
pcb: 0xcccf440
stack: 0xccce000-0xccd1fff <========== the range allowed
flags: 0x4 pflags: 0x100
state: RUNNING (CPU 0)
priority: 156
container lock: sched lock 0 (0x1efe240)
last voluntary switch: 0.010 s ago
last involuntary switch: 0.010 s ago
db> x/x kstack_pages
x/x kstack_pages
kstack_pages: 4 <========== how much kernel stack
space threads get
(gdb) list *sendsig+0x39a
0x131d6da is in sendsig (/usr/src/sys/i386/i386/exec_machdep.c:415).
410 regs = td->td_frame;
411 oonstack = sigonstack(regs->tf_esp);
412
413 if (cpu_max_ext_state_size > sizeof(union savefpu) &&
use_xsave) {
414 xfpusave_len = cpu_max_ext_state_size - sizeof(union
savefpu);
415 xfpusave = __builtin_alloca(xfpusave_len);
416 } else {
417 xfpusave_len = 0;
418 xfpusave = NULL;
419 }
*********
Please kindly help to take a look at this problem. If the component is not
correct, please also kindly help to change it.
Thanks!
Yanhui
--
You are receiving this mail because:
You are the assignee for the bug.