Bug 283276 - FreeBSD 13.x and FreeBSD 14.x 32bit fail during install on Intel Sapphire Rapids
Summary: FreeBSD 13.x and FreeBSD 14.x 32bit fail during install on Intel Sapphire Rapids
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 14.2-RELEASE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-12-12 04:02 UTC by Yanhui He
Modified: 2025-11-14 09:41 UTC (History)
3 users (show)

See Also:


Attachments
FreeBSD 14.2 32bit keep booting UI (36.95 KB, image/png)
2024-12-12 04:02 UTC, Yanhui He
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yanhui He 2024-12-12 04:02:46 UTC
Created attachment 255793 [details]
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
Comment 1 Konstantin Belousov freebsd_committer freebsd_triage 2024-12-12 05:16:22 UTC
It seems that you need to increase the kernel stack size, using either
kern.kstack_pages tunable, or recompile kernel with increased option
KSTACK_PAGES.

Why do you need to run i386 kernel on the modern hardware?
Comment 2 Yanhui He 2024-12-12 08:00:24 UTC
(In reply to Konstantin Belousov from comment #1)

Thanks Konstantin for your quick response!

Yes, if we reduce kernel stack space needed for FPU state in vm's configure file, it runs OK. But it just can be used when debugging.

FreeBSD 14.x 32bit still needs to be supported on vSphere product. Please refer to https://compatibilityguide.broadcom.com/search?program=software&persona=live&column=osVendors&order=asc&osFamilyName=%5BFreeBSD+14%5D&activePage=1&activeDelta=20

So, can we have solution about it now or in the next FreeBSD 13.x or 14.x release?

Thanks!
Yanhui
Comment 3 Konstantin Belousov freebsd_committer freebsd_triage 2024-12-12 10:41:06 UTC
(In reply to Yanhui He from comment #2)
I wrote exactly opposite: you need to increase the kernel stack size, either
with tunable, or by kernel recompilation.
Comment 4 Yanhui He 2024-12-13 02:52:10 UTC
(In reply to Konstantin Belousov from comment #3)
Thanks Konstantin for your correcting!
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2024-12-13 15:47:08 UTC
^Triage: reclassify.