Project

General

Profile

Actions

Bug #14685

open

Kernel panic on reroot

Added by Ed McLain over 1 year ago. Updated 7 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
Unknown
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Release Notes:
Default
Affected Plus Version:
23.05
Affected Architecture:
amd64

Description

When running a reroot on my firewall (Dell R220) it starts to stop services just fine then kernel panics and does a warm reboot. This has not been experienced prior to upgrading to v23.05 ( I upgraded from community 2.6.0 ).

Main panicis:
Panic String: vm_fault_lookup: fault on nofault entry, addr: 0xffffffff836cf000


Files

info.0 (594 Bytes) info.0 Ed McLain, 08/13/2023 08:26 PM
textdump.tar.0 (135 KB) textdump.tar.0 Ed McLain, 08/13/2023 08:26 PM
Actions #1

Updated by Jim Pingle over 1 year ago

  • Status changed from New to Not a Bug

The crash looks like it could potentially be a problem with the filesystem or disk. While there is a possibility it's a FreeBSD/OS bug, more likely you need to run several rounds of fsck on the disk (or wipe/reload) to ensure the filesystem is in good shape.

Trying to mount root from ufs:/dev/ufsid/64968bcf70d2e872 [rw,noatime]...
panic: vm_fault_lookup: fault on nofault entry, addr: 0xffffffff836cf000
cpuid = 3
time = 1691688424
KDB: enter: panic
db:1:pfs> bt
Tracing pid 1 tid 100002 td 0xfffffe0011383ac0
kdb_enter() at kdb_enter+0x32/frame 0xfffffe000fbaf900
vpanic() at vpanic+0x183/frame 0xfffffe000fbaf950
panic() at panic+0x43/frame 0xfffffe000fbaf9b0
vm_fault() at vm_fault+0x1539/frame 0xfffffe000fbafac0
vm_fault_trap() at vm_fault_trap+0xb1/frame 0xfffffe000fbafb10
trap_pfault() at trap_pfault+0x1f2/frame 0xfffffe000fbafb70
calltrap() at calltrap+0x8/frame 0xfffffe000fbafb70
--- trap 0xc, rip = 0xffffffff836cfe10, rsp = 0xfffffe000fbafc48, rbp = 0xfffffe000fbafdb0 ---
kmem_size_val() at 0xffffffff836cfe10/frame 0xfffffe000fbafdb0
sys_reboot() at sys_reboot+0x29c/frame 0xfffffe000fbafe00
amd64_syscall() at amd64_syscall+0x109/frame 0xfffffe000fbaff30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe000fbaff30
Actions #2

Updated by Mateusz Guzik 7 months ago

  • Status changed from Not a Bug to Feedback
  • Assignee set to Mateusz Guzik
Actions #3

Updated by Steve Wheeler 7 months ago

Since this bug is triggered by unloading the zfs module incorrectly on systems that do not require it also see: https://redmine.pfsense.org/issues/13183

Actions

Also available in: Atom PDF