(bugmeister note: I am forking this PR from 266730. They may, or may not, be related.) Originally from John F. Carr 2023-07-25 00:46:35 UTC: I saw what may be the same crash on amd64 running 12.4-CURRENT, first boot after upgrading from 12.3. I started the microcode_update service and the system promptly crashed. #4 0xffffffff810d66af in trap_fatal (frame=<value optimized out>, eva=<value optimized out>) at /data/freebsd/12/sys/amd64/amd64/trap.c:921 #5 0xffffffff810d66ff in trap_pfault (frame=0xfffffe002f78f9e0, signo=<value optimized out>, ucode=<value optimized out>) at pcpu_aux.h:55 #6 0xffffffff810aec68 in calltrap () at /data/freebsd/12/sys/amd64/amd64/exception.S:289 #7 0xffffffff810d2b73 in copyout_nosmap_std () at /data/freebsd/12/sys/amd64/amd64/support.S:805 #8 0xffffffff80c29f2d in uiomove_faultflag (cp=0xfffffe002686a000, n=98, uio=0xfffffe002f78fba0, nofault=<value optimized out>) at /data/freebsd/12/sys/kern/subr_uio.c:254 #9 0xffffffff80c32333 in pipe_read (fp=0xfffff80012598550, uio=0xfffffe002f78fba0, active_cred=<value optimized out>, flags=<value optimized out>, td=<value optimized out>) at /data/freebsd/12/sys/kern/sys_pipe.c:712 #10 0xffffffff80c2f3a5 in dofileread (td=<value optimized out>, fd=0, fp=<value optimized out>, auio=0xfffffe002f78fba0, offset=<value optimized out>, flags=<value optimized out>) at file.h:317 #11 0xffffffff80c2ef20 in sys_read (td=0xfffff8001cade740, uap=Unhandled dwarf expression opcode 0xa3 ) at /data/freebsd/12/sys/kern/sys_generic.c:289 #12 0xffffffff810d7267 in amd64_syscall (td=0xfffff8001cade740, traced=0) at subr_syscall.c:144 #13 0xffffffff810af58e in fast_syscall_common () at /data/freebsd/12/sys/amd64/amd64/exception.S:582 The active process was "logger".
John F. Carr 2024-01-14 00:58:27 UTC Today I updated my amd64 13.2-STABLE system for the first time in a month. It crashed with a similar error on the first boot. A microcode update caused a page fault trying to send data to the logger. core.txt contents below. This panic hadn't happened before on this system. Maybe the update to llvm17 affected code generation. Updating CPU Microcode... Fatal trap 12: page fault while in kernel mode cpuid = 45; apic id = 3b fault virtual address = 0x388e97560000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff81088c43 stack pointer = 0x28:0xfffffe03a79d7ca0 frame pointer = 0x28:0xfffffe03a79d7ca0 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 145 (logger) trap number = 12 panic: page fault cpuid = 45 time = 1705192820 KDB: stack backtrace: #0 0xffffffff80c199b5 at kdb_backtrace+0x65 #1 0xffffffff80bcebf2 at vpanic+0x152 #2 0xffffffff80bce9f3 at panic+0x43 #3 0xffffffff8108c56c at trap_fatal+0x38c #4 0xffffffff8108c5d7 at trap_pfault+0x67 #5 0xffffffff81060f08 at calltrap+0x8 #6 0xffffffff80c337d5 at uiomove_faultflag+0x135 [this is a call to copyout() -jfc] #7 0xffffffff80c3de55 at pipe_read+0x2f5 #8 0xffffffff80c3a586 at dofileread+0x86 #9 0xffffffff80c3a0d2 at sys_read+0xc2 #10 0xffffffff8108ced0 at amd64_syscall+0x140 #11 0xffffffff8106181b at fast_syscall_common+0xf8 Uptime: 38s
Is this happens during ucode update while the system is already booted? Can you try to load the update from boot loader? I wonder if the update did something like enabling SMAP.
Microcode update is late in /etc/rc processing after "Mounting local filesytems" but before a login prompt. SMAP is already enabled before the microcode is updated. The copyout call is bound to copyout_smap_std: 0xffffffff80c337ca <uiomove_faultflag+298>: mov %r15,%rdi 0xffffffff80c337cd <uiomove_faultflag+301>: mov %r12,%rdx 0xffffffff80c337d0 <uiomove_faultflag+304>: call 0xffffffff81088be0 <copyout_smap_std> When the crash is triggered, about once in 15 boots, it happens during /etc/rc script processing just before the system would go multi-user. The active processes in the latest crash are UID PID PPID C PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 25 -16 0 0 0 swapin DLs - 0:00.17 [kernel] 0 1 0 0 31 0 11780 836 wait DLs - 0:00.00 [init] 0 2 0 19 -16 0 0 0 - DL - 0:00.00 [KTLS] 0 3 0 47 -16 0 0 0 crypto_w DL - 0:00.00 [crypto] 0 4 0 41 -16 0 0 0 - DL - 0:00.00 [cam] 0 5 0 14 -16 0 0 0 - DL - 0:00.00 [rand_harvestq] 0 6 0 29 -16 0 0 0 idle DL - 0:00.00 [enc_daemon0] 0 7 0 3 -16 0 0 0 psleep DL - 0:00.00 [pagedaemon] 0 8 0 28 -16 0 0 0 psleep DL - 0:00.00 [vmdaemon] 0 9 0 22 -16 0 0 0 psleep DL - 0:00.00 [bufdaemon] 0 10 0 37 -16 0 0 0 audit_wo DL - 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL - 0:00.00 [idle] 0 12 0 -1 -52 0 0 0 - WL - 0:00.00 [intr] 0 13 0 39 20 0 0 0 - DL - 0:00.00 [geom] 0 14 0 32 -16 0 0 0 seqstate DL - 0:00.00 [sequencer 00] 0 15 0 11 -68 0 0 0 - DL - 0:00.00 [usb] 0 16 0 20 -16 0 0 0 vlruwt DL - 0:00.00 [vnlru] 0 17 0 14 16 0 0 0 syncer DL - 0:00.00 [syncer] 0 18 1 31 52 0 13552 2576 wait Ds+ - 0:00.00 [sh] 0 82 0 6 -8 0 0 0 t->zthr_ DL - 0:04.74 [zfskern] 0 139 18 43 52 0 13552 2588 wait D+ - 0:00.00 [sh] 0 144 139 0 52 0 12732 1868 pipelk D+ - 0:00.00 [cpucontrol] 0 145 139 45 52 0 12872 2176 - RC+ - 0:00.00 [logger] 0 148 1 31 52 0 12872 2052 select Ds - 0:00.00 [logger] This is my processor as reported early in boot: CPU: AMD EPYC 7402P 24-Core Processor (2794.96-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x830f10 Family=0x17 Model=0x31 Stepping=0 Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> Features2=0x7ed8320b<SSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM> AMD Features2=0x75c237ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT,TCE,Topology,PCXC,PNXC,DBE,PL2I,MWAITX,ADMSKX> Structured Extended Features=0x219c91a9<FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,PQE,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA> Structured Extended Features2=0x400004<UMIP,RDPID> XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES> AMD Extended Feature Extensions ID EBX=0x18cf757<CLZERO,IRPerf,XSaveErPtr,RDPRU,MCOMMIT,WBNOINVD,IBPB,IBRS,STIBP,PREFER_IBRS,PPIN,SSBD> SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics After update I have microcode version 0x830107a. I don't think the boot loader can install microcode on my AMD processor, only on an Intel processor.
> I don't think the boot loader can install microcode on my AMD processor, only on an Intel processor. That is true, but not for much longer hopefully. You might be willing to test https://reviews.freebsd.org/D43318
In the first message, the backtrace shows copyout_nosmap_std(). Anyway, do you observe a difference in the reported features before and after ucode load? Also, for the trap, disassemble the copyout function and show which instruction faulted.
The first crash is from AMD Excavator (Family 0x15) running 12.4. That processor is from 2015 and may not have SMAP. The second crash is from AMD Zen 2 (Family 0x17) running 13.2. That processor is from 2020 and has SMAP before microcode is loaded. Features do not change when microcode is loaded. In the code below the marked mov %rdx,(%rdi) at 0xffffffff81088c43 is the faulting instruction. The fault address is at the start of a page in the user address space and is the same as uio->uio_iov[0].iov_base, i.e. the first word to be written. The value of td->td_md.md_pcb.pcb_onfault is 0 in the dump image. I can't tell what it was while copyout was running. A comment says it should be non-null. 0xffffffff81088c1c <copyout_smap_std+60>: mov %rsi,%rdi 0xffffffff81088c1f <copyout_smap_std+63>: mov %r8,%rsi 0xffffffff81088c22 <copyout_smap_std+66>: mov %rdx,%rcx 0xffffffff81088c25 <copyout_smap_std+69>: stac 0xffffffff81088c28 <copyout_smap_std+72>: cmp $0x20,%rcx 0xffffffff81088c2c <copyout_smap_std+76>: jbe 0xffffffff81088c90 <copyout_smap_std+176> 0xffffffff81088c2e <copyout_smap_std+78>: cmp $0x100,%rcx 0xffffffff81088c35 <copyout_smap_std+85>: ja 0xffffffff81088d70 <copyout_smap_std+400> 0xffffffff81088c3b <copyout_smap_std+91>: nopl 0x0(%rax,%rax,1) 0xffffffff81088c40 <copyout_smap_std+96>: mov (%rsi),%rdx * 0xffffffff81088c43 <copyout_smap_std+99>: mov %rdx,(%rdi) 0xffffffff81088c46 <copyout_smap_std+102>: mov 0x8(%rsi),%rdx 0xffffffff81088c4a <copyout_smap_std+106>: mov %rdx,0x8(%rdi) 0xffffffff81088c4e <copyout_smap_std+110>: mov 0x10(%rsi),%rdx 0xffffffff81088c52 <copyout_smap_std+114>: mov %rdx,0x10(%rdi) 0xffffffff81088c56 <copyout_smap_std+118>: mov 0x18(%rsi),%rdx 0xffffffff81088c5a <copyout_smap_std+122>: mov %rdx,0x18(%rdi) 0xffffffff81088c5e <copyout_smap_std+126>: lea 0x20(%rsi),%rsi 0xffffffff81088c62 <copyout_smap_std+130>: lea 0x20(%rdi),%rdi 0xffffffff81088c66 <copyout_smap_std+134>: sub $0x20,%rcx
Other thread fields: td->td_critnest=1 which causes trap_pfault to panic before it even checks pcb_onfault td->td_pflags = 0x140 = TDP_DEADLKTREAT|TDP_SIGFASTBLOCK
(In reply to John F. Carr from comment #7) And what is the backtrace? td_critnest == 1 is extra strange, but pcb_onfault being NULL is also weird. Might be you are looking at wrong td.
Here is the complete backtrace (abbreviated form in comment #2) and evaluation of the td variable in that stack. (kgdb) bt #0 __curthread () at /usr/home/jfc/freebsd/src/sys/amd64/include/pcpu_aux.h:53 #1 doadump (textdump=<optimized out>) at /usr/home/jfc/freebsd/src/sys/kern/kern_shutdown.c:394 #2 0xffffffff80bce802 in kern_reboot (howto=260) at /usr/home/jfc/freebsd/src/sys/kern/kern_shutdown.c:482 #3 0xffffffff80bcec5f in vpanic (fmt=0xffffffff812041f3 "%s", ap=ap@entry=0xfffffe03a79d7af0) at /usr/home/jfc/freebsd/src/sys/kern/kern_shutdown.c:921 #4 0xffffffff80bce9f3 in panic (fmt=<unavailable>) at /usr/home/jfc/freebsd/src/sys/kern/kern_shutdown.c:845 #5 0xffffffff8108c56c in trap_fatal (frame=0xfffffe03a79d7be0, eva=62185075507200) at /usr/home/jfc/freebsd/src/sys/amd64/amd64/trap.c:940 #6 0xffffffff8108c5d7 in trap_pfault (frame=0xfffffe03a79d7be0, usermode=false, signo=<optimized out>, ucode=<optimized out>) at /usr/home/jfc/freebsd/src/sys/amd64/amd64/trap.c:759 #7 <signal handler called> #8 copyout_smap_std () at /usr/home/jfc/freebsd/src/sys/amd64/amd64/support.S:849 #9 0xffffffff80c337d5 in uiomove_faultflag (cp=0xfffffe01bedc0000, n=n@entry=105, uio=uio@entry=0xfffffe03a79d7da0, nofault=nofault@entry=0) at /usr/home/jfc/freebsd/src/sys/kern/subr_uio.c:256 #10 0xffffffff80c33699 in uiomove (cp=0x388e97560000, n=-1092878336, n@entry=105, uio=0x636f6c2f7273752f, uio@entry=0xfffffe03a79d7da0) at /usr/home/jfc/freebsd/src/sys/kern/subr_uio.c:196 #11 0xffffffff80c3de55 in pipe_read (fp=0xfffff801441abe10, uio=0xfffffe03a79d7da0, active_cred=<optimized out>, flags=<optimized out>, td=0xfffff80103c48000) at /usr/home/jfc/freebsd/src/sys/kern/sys_pipe.c:732 #12 0xffffffff80c3a586 in fo_read (fp=0xfffff801441abe10, uio=0xfffffe03a79d7da0, active_cred=0x636f6c2f7273752f, td=0xfffff80103c48000, flags=<optimized out>) at /usr/home/jfc/freebsd/src/sys/sys/file.h:336 #13 dofileread (td=td@entry=0xfffff80103c48000, fd=fd@entry=0, fp=0xfffff801441abe10, auio=auio@entry=0xfffffe03a79d7da0, offset=offset@entry=-1, flags=flags@entry=0) at /usr/home/jfc/freebsd/src/sys/kern/sys_generic.c:367 #14 0xffffffff80c3a0d2 in kern_readv (td=0xfffff80103c48000, fd=0, auio=0xfffffe03a79d7da0) at /usr/home/jfc/freebsd/src/sys/kern/sys_generic.c:288 #15 sys_read (td=0xfffff80103c48000, uap=<optimized out>) at /usr/home/jfc/freebsd/src/sys/kern/sys_generic.c:204 #16 0xffffffff8108ced0 in syscallenter (td=<optimized out>) at /usr/home/jfc/freebsd/src/sys/amd64/amd64/../../kern/subr_syscall.c:188 #17 amd64_syscall (td=0xfffff80103c48000, traced=0) at /usr/home/jfc/freebsd/src/sys/amd64/amd64/trap.c:1181 #18 <signal handler called> #19 0x0000388e94230d9a in ?? () Backtrace stopped: Cannot access memory at address 0x388e93262428 (kgdb) up 13 #13 dofileread (td=td@entry=0xfffff80103c48000, fd=fd@entry=0, fp=0xfffff801441abe10, auio=auio@entry=0xfffffe03a79d7da0, offset=offset@entry=-1, flags=flags@entry=0) at /usr/home/jfc/freebsd/src/sys/kern/sys_generic.c:367 367 if ((error = fo_read(fp, auio, td->td_ucred, flags, td))) { (kgdb) p td->td_critnest $22 = 1 (kgdb) p/x td->td_md.md_pcb $23 = {pcb_r15 = 0xfffff80101bba000, pcb_r14 = 0xffffffff81e97788, pcb_r13 = 0xfffffe010aeec0d8, pcb_r12 = 0xfffffe010aeec0c0, pcb_rbp = 0xfffffe03a79d7bb0, pcb_rsp = 0xfffffe03a79d7b18, pcb_rbx = 0xfffff80103c48000, pcb_rip = 0xffffffff80bfe4b6, pcb_fsbase = 0x388e9378c120, pcb_gsbase = 0x0, pcb_kgsbase = 0x0, pcb_cr0 = 0x0, pcb_cr2 = 0x0, pcb_cr3 = 0x0, pcb_cr4 = 0x0, pcb_dr0 = 0x0, pcb_dr1 = 0x0, pcb_dr2 = 0x0, pcb_dr3 = 0x0, pcb_dr6 = 0x0, pcb_dr7 = 0x0, pcb_gdt = {rd_limit = 0x0, rd_base = 0x0}, pcb_idt = {rd_limit = 0x0, rd_base = 0x0}, pcb_ldt = {rd_limit = 0x0, rd_base = 0x0}, pcb_tr = 0x0, pcb_flags = 0x19, pcb_initial_fpucw = 0x37f, pcb_onfault = 0x0, pcb_saved_ucr3 = 0x0, pcb_tssp = 0x0, pcb_efer = 0x0, pcb_star = 0x0, pcb_lstar = 0x0, pcb_cstar = 0x0, pcb_sfmask = 0x0, pcb_save = 0xfffffe02699f4c00, pcb_pad = {0x0, 0x0, 0x0, 0x0, 0x0}} (kgdb)
(In reply to Konstantin Belousov from comment #8) td_critnest == 1 is probably a side effect of panic(), which calls spinlock_enter().
The stack trace goes through line 759 in trap.c. In my code that is the if statement here: if (td->td_critnest != 0 || WITNESS_CHECK(WARN_SLEEPOK | WARN_GIANTOK, NULL, "Kernel page fault") != 0) { trap_fatal(frame, eva); return (-1); } That prompted me to check td->td_critnest. The WITNESS_CHECK should return 0. I have WITNESS disabled. I have INVARIANTS enabled. Otherwise my kernel is GENERIC. Could we be getting a page fault handling a page fault? I don't know if that can be reconciled with the stack.
(In reply to Mark Johnston from comment #10) It could be due to panic(), but then it is not clear why trap_pfault() called trap_fatal() at line 759. Either td_critnest was > 0, or we owned some non-sleepable lock, and the later would only trigger if the witness was compiled in.
https://reviews.freebsd.org/D43639
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=486b265a8fb6b2aad37f2819fa04feacf8184d53 commit 486b265a8fb6b2aad37f2819fa04feacf8184d53 Author: Andriy Gapon <avg@FreeBSD.org> AuthorDate: 2024-01-30 06:45:01 +0000 Commit: Andriy Gapon <avg@FreeBSD.org> CommitDate: 2024-01-30 06:45:01 +0000 rdmsr_safe/wrmsr_safe: handle pcb_onfault nesting rdmsr_safe and wrmsr_safe can be called while pcb_onfault is already set, so the functions are modified to preserve the handler rather than resetting it before returning. One case where that happens is when AMD microcode update routine is executed on a stack where copyin / copyout was already active. Here is a sample panic message from a crash caused by resetting the handler: <118>Updating CPU Microcode... Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x11ed0de6000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80c2df03 stack pointer = 0x28:0xfffffe01ce4a4c70 frame pointer = 0x28:0xfffffe01ce4a4c70 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 117 (logger) trap number = 12 panic: page fault cpuid = 3 time = 1681462027 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff80615deb = db_trace_self_wrapper+0x2b/frame 0xfffffe01ce4a4830 kdb_backtrace() at 0xffffffff80943c77 = kdb_backtrace+0x37/frame 0xfffffe01ce4a48e0 vpanic() at 0xffffffff808f5fe5 = vpanic+0x185/frame 0xfffffe01ce4a4940 panic() at 0xffffffff808f5da3 = panic+0x43/frame 0xfffffe01ce4a49a0 trap_fatal() at 0xffffffff80c31849 = trap_fatal+0x379/frame 0xfffffe01ce4a4a00 trap_pfault() at 0xffffffff80c318b5 = trap_pfault+0x65/frame 0xfffffe01ce4a4a60 trap() at 0xffffffff80c30f5f = trap+0x29f/frame 0xfffffe01ce4a4b80 trap_check() at 0xffffffff80c31c29 = trap_check+0x29/frame 0xfffffe01ce4a4ba0 calltrap() at 0xffffffff80c07fd8 = calltrap+0x8/frame 0xfffffe01ce4a4ba0 --- trap 0xc, rip = 0xffffffff80c2df03, rsp = 0xfffffe01ce4a4c70, rbp = 0xfffffe01ce4a4c70 --- copyout_nosmap_std() at 0xffffffff80c2df03 = copyout_nosmap_std+0x63/frame 0xfffffe01ce4a4c70 uiomove_faultflag() at 0xffffffff8095f0d5 = uiomove_faultflag+0xe5/frame 0xfffffe01ce4a4cb0 uiomove() at 0xffffffff8095efeb = uiomove+0xb/frame 0xfffffe01ce4a4cc0 pipe_read() at 0xffffffff80968860 = pipe_read+0x230/frame 0xfffffe01ce4a4d30 dofileread() at 0xffffffff809653cb = dofileread+0x8b/frame 0xfffffe01ce4a4d80 sys_read() at 0xffffffff80964fa0 = sys_read+0xc0/frame 0xfffffe01ce4a4df0 amd64_syscall() at 0xffffffff80c3221a = amd64_syscall+0x18a/frame 0xfffffe01ce4a4f30 fast_syscall_common() at 0xffffffff80c088eb = fast_syscall_common+0xf8/frame 0xfffffe01ce4a4f30 --- syscall (3, FreeBSD ELF64, read), rip = 0x11ece41cfaa, rsp = 0x11ecbec4908, rbp = 0x11ecbec4920 --- Uptime: 41s And another one: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x800a22000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80b2c7ca stack pointer = 0x28:0xfffffe01c55b5480 frame pointer = 0x28:0xfffffe01c55b5480 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 68418 (pfctl) trap number = 12 panic: page fault cpuid = 4 time = 1625184463 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff805c1e8b = db_trace_self_wrapper+0x2b/frame 0xfffffe01c55b5040 kdb_backtrace() at 0xffffffff808874b7 = kdb_backtrace+0x37/frame 0xfffffe01c55b50f0 vpanic() at 0xffffffff808449d8 = vpanic+0x188/frame 0xfffffe01c55b5150 panic() at 0xffffffff808445f3 = panic+0x43/frame 0xfffffe01c55b51b0 trap_fatal() at 0xffffffff80b300a5 = trap_fatal+0x375/frame 0xfffffe01c55b5210 trap_pfault() at 0xffffffff80b30180 = trap_pfault+0x80/frame 0xfffffe01c55b5280 trap() at 0xffffffff80b2f729 = trap+0x289/frame 0xfffffe01c55b5390 trap_check() at 0xffffffff80b304d9 = trap_check+0x29/frame 0xfffffe01c55b53b0 calltrap() at 0xffffffff80b0bb28 = calltrap+0x8/frame 0xfffffe01c55b53b0 --- trap 0xc, rip = 0xffffffff80b2c7ca, rsp = 0xfffffe01c55b5480, rbp = 0xfffffe01c55b5480 --- copyout_nosmap_std() at 0xffffffff80b2c7ca = copyout_nosmap_std+0x15a/frame 0xfffffe01c55b5480 pfioctl() at 0xffffffff85539358 = pfioctl+0x4d28/frame 0xfffffe01c55b5940 devfs_ioctl() at 0xffffffff807176cf = devfs_ioctl+0xcf/frame 0xfffffe01c55b59a0 VOP_IOCTL_APV() at 0xffffffff80bb26e2 = VOP_IOCTL_APV+0x92/frame 0xfffffe01c55b59c0 VOP_IOCTL() at 0xffffffff80928014 = VOP_IOCTL+0x34/frame 0xfffffe01c55b5a10 vn_ioctl() at 0xffffffff80923330 = vn_ioctl+0xc0/frame 0xfffffe01c55b5b00 devfs_ioctl_f() at 0xffffffff80717bbe = devfs_ioctl_f+0x1e/frame 0xfffffe01c55b5b20 fo_ioctl() at 0xffffffff808abc6b = fo_ioctl+0xb/frame 0xfffffe01c55b5b30 kern_ioctl() at 0xffffffff808abc01 = kern_ioctl+0x1d1/frame 0xfffffe01c55b5b80 sys_ioctl() at 0xffffffff808ab982 = sys_ioctl+0x132/frame 0xfffffe01c55b5c50 syscallenter() at 0xffffffff80b30cc9 = syscallenter+0x159/frame 0xfffffe01c55b5ca0 amd64_syscall() at 0xffffffff80b309a5 = amd64_syscall+0x15/frame 0xfffffe01c55b5d30 fast_syscall_common() at 0xffffffff80b0c44e = fast_syscall_common+0xf8/frame 0xfffffe01c55b5d30 PR: 276426 Reviewed by: kib, markj MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D43639 sys/amd64/amd64/support.S | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=007b84e6c159c5cf0d42923877868afee6c2d523 commit 007b84e6c159c5cf0d42923877868afee6c2d523 Author: Andriy Gapon <avg@FreeBSD.org> AuthorDate: 2024-01-30 06:45:01 +0000 Commit: Andriy Gapon <avg@FreeBSD.org> CommitDate: 2024-02-17 14:18:20 +0000 rdmsr_safe/wrmsr_safe: handle pcb_onfault nesting rdmsr_safe and wrmsr_safe can be called while pcb_onfault is already set, so the functions are modified to preserve the handler rather than resetting it before returning. One case where that happens is when AMD microcode update routine is executed on a stack where copyin / copyout was already active. Here is a sample panic message from a crash caused by resetting the handler: <118>Updating CPU Microcode... Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x11ed0de6000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80c2df03 stack pointer = 0x28:0xfffffe01ce4a4c70 frame pointer = 0x28:0xfffffe01ce4a4c70 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 117 (logger) trap number = 12 panic: page fault cpuid = 3 time = 1681462027 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff80615deb = db_trace_self_wrapper+0x2b/frame 0xfffffe01ce4a4830 kdb_backtrace() at 0xffffffff80943c77 = kdb_backtrace+0x37/frame 0xfffffe01ce4a48e0 vpanic() at 0xffffffff808f5fe5 = vpanic+0x185/frame 0xfffffe01ce4a4940 panic() at 0xffffffff808f5da3 = panic+0x43/frame 0xfffffe01ce4a49a0 trap_fatal() at 0xffffffff80c31849 = trap_fatal+0x379/frame 0xfffffe01ce4a4a00 trap_pfault() at 0xffffffff80c318b5 = trap_pfault+0x65/frame 0xfffffe01ce4a4a60 trap() at 0xffffffff80c30f5f = trap+0x29f/frame 0xfffffe01ce4a4b80 trap_check() at 0xffffffff80c31c29 = trap_check+0x29/frame 0xfffffe01ce4a4ba0 calltrap() at 0xffffffff80c07fd8 = calltrap+0x8/frame 0xfffffe01ce4a4ba0 --- trap 0xc, rip = 0xffffffff80c2df03, rsp = 0xfffffe01ce4a4c70, rbp = 0xfffffe01ce4a4c70 --- copyout_nosmap_std() at 0xffffffff80c2df03 = copyout_nosmap_std+0x63/frame 0xfffffe01ce4a4c70 uiomove_faultflag() at 0xffffffff8095f0d5 = uiomove_faultflag+0xe5/frame 0xfffffe01ce4a4cb0 uiomove() at 0xffffffff8095efeb = uiomove+0xb/frame 0xfffffe01ce4a4cc0 pipe_read() at 0xffffffff80968860 = pipe_read+0x230/frame 0xfffffe01ce4a4d30 dofileread() at 0xffffffff809653cb = dofileread+0x8b/frame 0xfffffe01ce4a4d80 sys_read() at 0xffffffff80964fa0 = sys_read+0xc0/frame 0xfffffe01ce4a4df0 amd64_syscall() at 0xffffffff80c3221a = amd64_syscall+0x18a/frame 0xfffffe01ce4a4f30 fast_syscall_common() at 0xffffffff80c088eb = fast_syscall_common+0xf8/frame 0xfffffe01ce4a4f30 --- syscall (3, FreeBSD ELF64, read), rip = 0x11ece41cfaa, rsp = 0x11ecbec4908, rbp = 0x11ecbec4920 --- Uptime: 41s And another one: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x800a22000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80b2c7ca stack pointer = 0x28:0xfffffe01c55b5480 frame pointer = 0x28:0xfffffe01c55b5480 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 68418 (pfctl) trap number = 12 panic: page fault cpuid = 4 time = 1625184463 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff805c1e8b = db_trace_self_wrapper+0x2b/frame 0xfffffe01c55b5040 kdb_backtrace() at 0xffffffff808874b7 = kdb_backtrace+0x37/frame 0xfffffe01c55b50f0 vpanic() at 0xffffffff808449d8 = vpanic+0x188/frame 0xfffffe01c55b5150 panic() at 0xffffffff808445f3 = panic+0x43/frame 0xfffffe01c55b51b0 trap_fatal() at 0xffffffff80b300a5 = trap_fatal+0x375/frame 0xfffffe01c55b5210 trap_pfault() at 0xffffffff80b30180 = trap_pfault+0x80/frame 0xfffffe01c55b5280 trap() at 0xffffffff80b2f729 = trap+0x289/frame 0xfffffe01c55b5390 trap_check() at 0xffffffff80b304d9 = trap_check+0x29/frame 0xfffffe01c55b53b0 calltrap() at 0xffffffff80b0bb28 = calltrap+0x8/frame 0xfffffe01c55b53b0 --- trap 0xc, rip = 0xffffffff80b2c7ca, rsp = 0xfffffe01c55b5480, rbp = 0xfffffe01c55b5480 --- copyout_nosmap_std() at 0xffffffff80b2c7ca = copyout_nosmap_std+0x15a/frame 0xfffffe01c55b5480 pfioctl() at 0xffffffff85539358 = pfioctl+0x4d28/frame 0xfffffe01c55b5940 devfs_ioctl() at 0xffffffff807176cf = devfs_ioctl+0xcf/frame 0xfffffe01c55b59a0 VOP_IOCTL_APV() at 0xffffffff80bb26e2 = VOP_IOCTL_APV+0x92/frame 0xfffffe01c55b59c0 VOP_IOCTL() at 0xffffffff80928014 = VOP_IOCTL+0x34/frame 0xfffffe01c55b5a10 vn_ioctl() at 0xffffffff80923330 = vn_ioctl+0xc0/frame 0xfffffe01c55b5b00 devfs_ioctl_f() at 0xffffffff80717bbe = devfs_ioctl_f+0x1e/frame 0xfffffe01c55b5b20 fo_ioctl() at 0xffffffff808abc6b = fo_ioctl+0xb/frame 0xfffffe01c55b5b30 kern_ioctl() at 0xffffffff808abc01 = kern_ioctl+0x1d1/frame 0xfffffe01c55b5b80 sys_ioctl() at 0xffffffff808ab982 = sys_ioctl+0x132/frame 0xfffffe01c55b5c50 syscallenter() at 0xffffffff80b30cc9 = syscallenter+0x159/frame 0xfffffe01c55b5ca0 amd64_syscall() at 0xffffffff80b309a5 = amd64_syscall+0x15/frame 0xfffffe01c55b5d30 fast_syscall_common() at 0xffffffff80b0c44e = fast_syscall_common+0xf8/frame 0xfffffe01c55b5d30 PR: 276426 Reviewed by: kib, markj MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D43639 (cherry picked from commit 486b265a8fb6b2aad37f2819fa04feacf8184d53) sys/amd64/amd64/support.S | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5d24ae53b622507410d6befc5e3b8a7911991175 commit 5d24ae53b622507410d6befc5e3b8a7911991175 Author: Andriy Gapon <avg@FreeBSD.org> AuthorDate: 2024-01-30 06:45:01 +0000 Commit: Andriy Gapon <avg@FreeBSD.org> CommitDate: 2024-02-17 19:22:09 +0000 rdmsr_safe/wrmsr_safe: handle pcb_onfault nesting rdmsr_safe and wrmsr_safe can be called while pcb_onfault is already set, so the functions are modified to preserve the handler rather than resetting it before returning. One case where that happens is when AMD microcode update routine is executed on a stack where copyin / copyout was already active. Here is a sample panic message from a crash caused by resetting the handler: <118>Updating CPU Microcode... Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x11ed0de6000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80c2df03 stack pointer = 0x28:0xfffffe01ce4a4c70 frame pointer = 0x28:0xfffffe01ce4a4c70 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 117 (logger) trap number = 12 panic: page fault cpuid = 3 time = 1681462027 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff80615deb = db_trace_self_wrapper+0x2b/frame 0xfffffe01ce4a4830 kdb_backtrace() at 0xffffffff80943c77 = kdb_backtrace+0x37/frame 0xfffffe01ce4a48e0 vpanic() at 0xffffffff808f5fe5 = vpanic+0x185/frame 0xfffffe01ce4a4940 panic() at 0xffffffff808f5da3 = panic+0x43/frame 0xfffffe01ce4a49a0 trap_fatal() at 0xffffffff80c31849 = trap_fatal+0x379/frame 0xfffffe01ce4a4a00 trap_pfault() at 0xffffffff80c318b5 = trap_pfault+0x65/frame 0xfffffe01ce4a4a60 trap() at 0xffffffff80c30f5f = trap+0x29f/frame 0xfffffe01ce4a4b80 trap_check() at 0xffffffff80c31c29 = trap_check+0x29/frame 0xfffffe01ce4a4ba0 calltrap() at 0xffffffff80c07fd8 = calltrap+0x8/frame 0xfffffe01ce4a4ba0 --- trap 0xc, rip = 0xffffffff80c2df03, rsp = 0xfffffe01ce4a4c70, rbp = 0xfffffe01ce4a4c70 --- copyout_nosmap_std() at 0xffffffff80c2df03 = copyout_nosmap_std+0x63/frame 0xfffffe01ce4a4c70 uiomove_faultflag() at 0xffffffff8095f0d5 = uiomove_faultflag+0xe5/frame 0xfffffe01ce4a4cb0 uiomove() at 0xffffffff8095efeb = uiomove+0xb/frame 0xfffffe01ce4a4cc0 pipe_read() at 0xffffffff80968860 = pipe_read+0x230/frame 0xfffffe01ce4a4d30 dofileread() at 0xffffffff809653cb = dofileread+0x8b/frame 0xfffffe01ce4a4d80 sys_read() at 0xffffffff80964fa0 = sys_read+0xc0/frame 0xfffffe01ce4a4df0 amd64_syscall() at 0xffffffff80c3221a = amd64_syscall+0x18a/frame 0xfffffe01ce4a4f30 fast_syscall_common() at 0xffffffff80c088eb = fast_syscall_common+0xf8/frame 0xfffffe01ce4a4f30 --- syscall (3, FreeBSD ELF64, read), rip = 0x11ece41cfaa, rsp = 0x11ecbec4908, rbp = 0x11ecbec4920 --- Uptime: 41s And another one: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x800a22000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80b2c7ca stack pointer = 0x28:0xfffffe01c55b5480 frame pointer = 0x28:0xfffffe01c55b5480 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 68418 (pfctl) trap number = 12 panic: page fault cpuid = 4 time = 1625184463 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff805c1e8b = db_trace_self_wrapper+0x2b/frame 0xfffffe01c55b5040 kdb_backtrace() at 0xffffffff808874b7 = kdb_backtrace+0x37/frame 0xfffffe01c55b50f0 vpanic() at 0xffffffff808449d8 = vpanic+0x188/frame 0xfffffe01c55b5150 panic() at 0xffffffff808445f3 = panic+0x43/frame 0xfffffe01c55b51b0 trap_fatal() at 0xffffffff80b300a5 = trap_fatal+0x375/frame 0xfffffe01c55b5210 trap_pfault() at 0xffffffff80b30180 = trap_pfault+0x80/frame 0xfffffe01c55b5280 trap() at 0xffffffff80b2f729 = trap+0x289/frame 0xfffffe01c55b5390 trap_check() at 0xffffffff80b304d9 = trap_check+0x29/frame 0xfffffe01c55b53b0 calltrap() at 0xffffffff80b0bb28 = calltrap+0x8/frame 0xfffffe01c55b53b0 --- trap 0xc, rip = 0xffffffff80b2c7ca, rsp = 0xfffffe01c55b5480, rbp = 0xfffffe01c55b5480 --- copyout_nosmap_std() at 0xffffffff80b2c7ca = copyout_nosmap_std+0x15a/frame 0xfffffe01c55b5480 pfioctl() at 0xffffffff85539358 = pfioctl+0x4d28/frame 0xfffffe01c55b5940 devfs_ioctl() at 0xffffffff807176cf = devfs_ioctl+0xcf/frame 0xfffffe01c55b59a0 VOP_IOCTL_APV() at 0xffffffff80bb26e2 = VOP_IOCTL_APV+0x92/frame 0xfffffe01c55b59c0 VOP_IOCTL() at 0xffffffff80928014 = VOP_IOCTL+0x34/frame 0xfffffe01c55b5a10 vn_ioctl() at 0xffffffff80923330 = vn_ioctl+0xc0/frame 0xfffffe01c55b5b00 devfs_ioctl_f() at 0xffffffff80717bbe = devfs_ioctl_f+0x1e/frame 0xfffffe01c55b5b20 fo_ioctl() at 0xffffffff808abc6b = fo_ioctl+0xb/frame 0xfffffe01c55b5b30 kern_ioctl() at 0xffffffff808abc01 = kern_ioctl+0x1d1/frame 0xfffffe01c55b5b80 sys_ioctl() at 0xffffffff808ab982 = sys_ioctl+0x132/frame 0xfffffe01c55b5c50 syscallenter() at 0xffffffff80b30cc9 = syscallenter+0x159/frame 0xfffffe01c55b5ca0 amd64_syscall() at 0xffffffff80b309a5 = amd64_syscall+0x15/frame 0xfffffe01c55b5d30 fast_syscall_common() at 0xffffffff80b0c44e = fast_syscall_common+0xf8/frame 0xfffffe01c55b5d30 PR: 276426 Reviewed by: kib, markj MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D43639 (cherry picked from commit 486b265a8fb6b2aad37f2819fa04feacf8184d53) sys/amd64/amd64/support.S | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
A commit in branch releng/13.3 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=75316a59b39ee83ed8b0e98597abb7baeea6a788 commit 75316a59b39ee83ed8b0e98597abb7baeea6a788 Author: Andriy Gapon <avg@FreeBSD.org> AuthorDate: 2024-01-30 06:45:01 +0000 Commit: Andriy Gapon <avg@FreeBSD.org> CommitDate: 2024-02-19 09:51:07 +0000 rdmsr_safe/wrmsr_safe: handle pcb_onfault nesting rdmsr_safe and wrmsr_safe can be called while pcb_onfault is already set, so the functions are modified to preserve the handler rather than resetting it before returning. One case where that happens is when AMD microcode update routine is executed on a stack where copyin / copyout was already active. Here is a sample panic message from a crash caused by resetting the handler: <118>Updating CPU Microcode... Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x11ed0de6000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80c2df03 stack pointer = 0x28:0xfffffe01ce4a4c70 frame pointer = 0x28:0xfffffe01ce4a4c70 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 117 (logger) trap number = 12 panic: page fault cpuid = 3 time = 1681462027 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff80615deb = db_trace_self_wrapper+0x2b/frame 0xfffffe01ce4a4830 kdb_backtrace() at 0xffffffff80943c77 = kdb_backtrace+0x37/frame 0xfffffe01ce4a48e0 vpanic() at 0xffffffff808f5fe5 = vpanic+0x185/frame 0xfffffe01ce4a4940 panic() at 0xffffffff808f5da3 = panic+0x43/frame 0xfffffe01ce4a49a0 trap_fatal() at 0xffffffff80c31849 = trap_fatal+0x379/frame 0xfffffe01ce4a4a00 trap_pfault() at 0xffffffff80c318b5 = trap_pfault+0x65/frame 0xfffffe01ce4a4a60 trap() at 0xffffffff80c30f5f = trap+0x29f/frame 0xfffffe01ce4a4b80 trap_check() at 0xffffffff80c31c29 = trap_check+0x29/frame 0xfffffe01ce4a4ba0 calltrap() at 0xffffffff80c07fd8 = calltrap+0x8/frame 0xfffffe01ce4a4ba0 --- trap 0xc, rip = 0xffffffff80c2df03, rsp = 0xfffffe01ce4a4c70, rbp = 0xfffffe01ce4a4c70 --- copyout_nosmap_std() at 0xffffffff80c2df03 = copyout_nosmap_std+0x63/frame 0xfffffe01ce4a4c70 uiomove_faultflag() at 0xffffffff8095f0d5 = uiomove_faultflag+0xe5/frame 0xfffffe01ce4a4cb0 uiomove() at 0xffffffff8095efeb = uiomove+0xb/frame 0xfffffe01ce4a4cc0 pipe_read() at 0xffffffff80968860 = pipe_read+0x230/frame 0xfffffe01ce4a4d30 dofileread() at 0xffffffff809653cb = dofileread+0x8b/frame 0xfffffe01ce4a4d80 sys_read() at 0xffffffff80964fa0 = sys_read+0xc0/frame 0xfffffe01ce4a4df0 amd64_syscall() at 0xffffffff80c3221a = amd64_syscall+0x18a/frame 0xfffffe01ce4a4f30 fast_syscall_common() at 0xffffffff80c088eb = fast_syscall_common+0xf8/frame 0xfffffe01ce4a4f30 --- syscall (3, FreeBSD ELF64, read), rip = 0x11ece41cfaa, rsp = 0x11ecbec4908, rbp = 0x11ecbec4920 --- Uptime: 41s And another one: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x800a22000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80b2c7ca stack pointer = 0x28:0xfffffe01c55b5480 frame pointer = 0x28:0xfffffe01c55b5480 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 68418 (pfctl) trap number = 12 panic: page fault cpuid = 4 time = 1625184463 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff805c1e8b = db_trace_self_wrapper+0x2b/frame 0xfffffe01c55b5040 kdb_backtrace() at 0xffffffff808874b7 = kdb_backtrace+0x37/frame 0xfffffe01c55b50f0 vpanic() at 0xffffffff808449d8 = vpanic+0x188/frame 0xfffffe01c55b5150 panic() at 0xffffffff808445f3 = panic+0x43/frame 0xfffffe01c55b51b0 trap_fatal() at 0xffffffff80b300a5 = trap_fatal+0x375/frame 0xfffffe01c55b5210 trap_pfault() at 0xffffffff80b30180 = trap_pfault+0x80/frame 0xfffffe01c55b5280 trap() at 0xffffffff80b2f729 = trap+0x289/frame 0xfffffe01c55b5390 trap_check() at 0xffffffff80b304d9 = trap_check+0x29/frame 0xfffffe01c55b53b0 calltrap() at 0xffffffff80b0bb28 = calltrap+0x8/frame 0xfffffe01c55b53b0 --- trap 0xc, rip = 0xffffffff80b2c7ca, rsp = 0xfffffe01c55b5480, rbp = 0xfffffe01c55b5480 --- copyout_nosmap_std() at 0xffffffff80b2c7ca = copyout_nosmap_std+0x15a/frame 0xfffffe01c55b5480 pfioctl() at 0xffffffff85539358 = pfioctl+0x4d28/frame 0xfffffe01c55b5940 devfs_ioctl() at 0xffffffff807176cf = devfs_ioctl+0xcf/frame 0xfffffe01c55b59a0 VOP_IOCTL_APV() at 0xffffffff80bb26e2 = VOP_IOCTL_APV+0x92/frame 0xfffffe01c55b59c0 VOP_IOCTL() at 0xffffffff80928014 = VOP_IOCTL+0x34/frame 0xfffffe01c55b5a10 vn_ioctl() at 0xffffffff80923330 = vn_ioctl+0xc0/frame 0xfffffe01c55b5b00 devfs_ioctl_f() at 0xffffffff80717bbe = devfs_ioctl_f+0x1e/frame 0xfffffe01c55b5b20 fo_ioctl() at 0xffffffff808abc6b = fo_ioctl+0xb/frame 0xfffffe01c55b5b30 kern_ioctl() at 0xffffffff808abc01 = kern_ioctl+0x1d1/frame 0xfffffe01c55b5b80 sys_ioctl() at 0xffffffff808ab982 = sys_ioctl+0x132/frame 0xfffffe01c55b5c50 syscallenter() at 0xffffffff80b30cc9 = syscallenter+0x159/frame 0xfffffe01c55b5ca0 amd64_syscall() at 0xffffffff80b309a5 = amd64_syscall+0x15/frame 0xfffffe01c55b5d30 fast_syscall_common() at 0xffffffff80b0c44e = fast_syscall_common+0xf8/frame 0xfffffe01c55b5d30 PR: 276426 Reviewed by: kib, markj Approved by: re (cperciva) (cherry picked from commit 486b265a8fb6b2aad37f2819fa04feacf8184d53) sys/amd64/amd64/support.S | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
I would greatly appreciate if anyone could confirm that the problem is fixed in 13.3 (the latest RC or a custom build from releng/13.3). Thank you.