[Bug 283276] FreeBSD 13.x and FreeBSD 14.x 32bit fail during install on Intel Sapphire Rapids

From: <bugzilla-noreply_at_freebsd.org>
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.