[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.