Bug 251274 - panic: recursive fpu_kern_enter while in PCB_FPUNOSAVE state
Summary: panic: recursive fpu_kern_enter while in PCB_FPUNOSAVE state
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL: https://files.wilbury.net/s/PEFKeJQny...
Keywords: crash
Depends on:
Blocks:
 
Reported: 2020-11-20 15:50 UTC by Juraj Lutter
Modified: 2022-10-12 00:48 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Juraj Lutter freebsd_committer freebsd_triage 2020-11-20 15:50:49 UTC 
While booting r367891 a panic occurs.
See file in URL for dmesg.

Kernel config:
----8<----------
include GENERIC
ident   BNTS-NVS
options         RATELIMIT               # TX rate limiting support
options         TCPHPTS
----8<----------
Comment 1 Konstantin Belousov freebsd_committer freebsd_triage 2020-11-21 23:47:24 UTC 
This is double of #250351.

In both cases it sounds as if fpu_kern_exit() was forgotten.  I do not see
anything obvious in zfs code.
Comment 2 Juraj Lutter freebsd_committer freebsd_triage 2020-11-25 15:35:55 UTC 
With today's CURRENT and openzfs (sysutils/openzfs-kmod) I'm getting:

nda21: 1526185MB (3125627568 512 byte sectors)


Fatal trap 12: page fault while in kernel mode
cpuid = 27; apic id = 1b
fault virtual address	= 0x58
fault code		= supervisor read data, page not present
instruction pointer	= 0x20:0xffffffff80bc1f09
stack pointer	        = 0x28:0xfffffe01a3f59b80
frame pointer	        = 0x28:0xfffffe01a3f59bc0
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		= 1 (kernel)
trap number		= 12
panic: page fault
cpuid = 27
time = 115
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01a3f59830
vpanic() at vpanic+0x181/frame 0xfffffe01a3f59880
panic() at panic+0x43/frame 0xfffffe01a3f598e0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe01a3f59940
trap_pfault() at trap_pfault+0x97/frame 0xfffffe01a3f599a0
trap() at trap+0x2ab/frame 0xfffffe01a3f59ab0
calltrap() at calltrap+0x8/frame 0xfffffe01a3f59ab0
--- trap 0xc, rip = 0xffffffff80bc1f09, rsp = 0xfffffe01a3f59b80, rbp = 0xfffffe01a3f59bc0 ---
__mtx_lock_flags() at __mtx_lock_flags+0x49/frame 0xfffffe01a3f59bc0
zone_dataset_visible() at zone_dataset_visible+0x6b/frame 0xfffffe01a3f59c10
zfs_mount() at zfs_mount+0x26c/frame 0xfffffe01a3f59d90
vfs_domount() at vfs_domount+0x89c/frame 0xfffffe01a3f5a000
vfs_donmount() at vfs_donmount+0x872/frame 0xfffffe01a3f5a0a0
kernel_mount() at kernel_mount+0x57/frame 0xfffffe01a3f5a0f0
parse_mount() at parse_mount+0x4a1/frame 0xfffffe01a3f5a230
vfs_mountroot() at vfs_mountroot+0x589/frame 0xfffffe01a3f5a3a0
start_init() at start_init+0x1f/frame 0xfffffe01a3f5a430
fork_exit() at fork_exit+0x80/frame 0xfffffe01a3f5a470
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01a3f5a470
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 1 tid 100002 ]
Stopped at      kdb_enter+0x37: movq    $0,0x10ac246(%rip)
Comment 3 Juraj Lutter freebsd_committer freebsd_triage 2020-11-25 15:36:13 UTC 
And this is happening on boot.