Bug 251274

Summary:	panic: recursive fpu_kern_enter while in PCB_FPUNOSAVE state
Product:	Base System	Reporter:	Juraj Lutter <otis>
Component:	kern	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed Overcome By Events
Severity:	Affects Only Me	CC:	kib
Priority:	---	Keywords:	crash
Version:	CURRENT
Hardware:	Any
OS:	Any
URL:	https://files.wilbury.net/s/PEFKeJQnyiQFFtW

Description Juraj Lutter freebsd_committer

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

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

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

2020-11-25 15:36:13 UTC

And this is happening on boot.