[Bug 278958] zfs panic: page fault in sync_dnodes_task

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 31 May 2024 15:17:21 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278958

--- Comment #4 from nunziotocci2000@gmail.com ---
We have not gotten arround to replacing the drive yet. Meanwhile we have a new
panic:

Fatal trap 12: page fault while in kernel mode
cpuid = 28; apic id = 1c
fault virtual address   = 0x0
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff80eb9c53
stack pointer           = 0x28:0xfffffe02b60c7b90
frame pointer           = 0x28:0xfffffe02b60c7bb0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 47378 (sshd)
rdi: ffffffff81a135a8 rsi: ffffffff81a135a8 rdx: 0000000000000000
rcx: fffff80a9be5dc60  r8: 0000000000000000  r9: fffff80a9be5dc60
rax: 0000000000000000 rbx: fffffe011d24f000 rbp: fffffe02b60c7bb0
r10: ffffffff81a135a8 r11: 0000000000000000 r12: 0000000000000000
r13: fffff8075191c2a0 r14: fffff807e1ed8240 r15: 0000000000000000
trap number             = 12
panic: page fault
cpuid = 28
time = 1717134122
KDB: stack backtrace:
#0 0xffffffff80b9009d at kdb_backtrace+0x5d
#1 0xffffffff80b431a2 at vpanic+0x132
#2 0xffffffff80b43063 at panic+0x43
#3 0xffffffff8100c85c at trap_fatal+0x40c
#4 0xffffffff8100c8af at trap_pfault+0x4f
#5 0xffffffff80fe3ac8 at calltrap+0x8
#6 0xffffffff80ebd5ab at vm_map_entry_delete+0x1b
#7 0xffffffff80eb8d0b at vm_map_delete+0x7b
#8 0xffffffff80ebd84c at vm_map_remove+0x9c
#9 0xffffffff80bb5f79 at pipeclose+0x2f9
#10 0xffffffff80bb5970 at pipe_close+0x60
#11 0xffffffff80ae2221 at _fdrop+0x11
#12 0xffffffff80ae543a at closef+0x24a
#13 0xffffffff80ae9194 at closefp_impl+0x64
#14 0xffffffff8100d119 at amd64_syscall+0x109
#15 0xffffffff80fe43db at fast_syscall_common+0xf8

Interestingly enough, the only process listed in the `ps` output of the
core.txt in a `pipewr` state was the `zfs send` of a backup.

Also, myself and my father have been working on our backups scripts and we've
had other issues with zfs described here:
https://forums.freebsd.org/threads/zfs-dataset-size-is-out-of-control-zfs-send-recv-hangs-on-random-datasets.93549/

-- 
You are receiving this mail because:
You are the assignee for the bug.