Date: Fri, 31 May 2024 15:17:21 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 278958] zfs panic: page fault in sync_dnodes_task Message-ID: <bug-278958-3630-8GB4cNgpno@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-278958-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-278958-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278958 --- 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 =3D 28; apic id =3D 1c fault virtual address =3D 0x0 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80eb9c53 stack pointer =3D 0x28:0xfffffe02b60c7b90 frame pointer =3D 0x28:0xfffffe02b60c7bb0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 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 =3D 12 panic: page fault cpuid =3D 28 time =3D 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-s= end-recv-hangs-on-random-datasets.93549/ --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-278958-3630-8GB4cNgpno>