Ständige Crashes meiner OPNsense

Started by Viplex92, July 16, 2024, 03:50:13 PM

Previous topic - Next topic
July 16, 2024, 03:50:13 PM Last Edit: July 16, 2024, 04:03:07 PM by Viplex92
Wie der Titel schon verrät, habe ich seit einiger Zeit alle paar Tage einen großen Crash meiner OPNsense. Betrieben wird das ganze bare metal auf einem Minisforum MS-01. Ich bekomme auch einen Crashreport dazu und schicke den immer feißig ab an die Entwickler. Das Problem tritt bei der aktuellsten Firmware, aber auch mit der vorherigen Firmware auf. Gibt es irgendwas, dass ich tun kann. Evtl. wird man aus dem Crashlog schlau? Irgendwie ist das so doof, weil ich immer damit rechnen muss, dass gleich wieder ein Crash kommt. Ich bezweifel, dass das Einsenden der Crashreports mir schnell weiterhelfen wird.

Was auffällig ist, ist dass es immer einen Kernel Panic gibt:

Fatal trap 9: general protection fault while in kernel mode
cpuid = 15; apic id = 36
instruction pointer = 0x20:0xffffffff811464b2
stack pointer         = 0x28:0xfffffe0125e7cbf0
frame pointer         = 0x28:0xfffffe0125e7cc20
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 = 69240 (python3.11)
trap number = 9
panic: general protection fault
cpuid = 15
time = 1720868700
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0125e7ca10
vpanic() at vpanic+0x151/frame 0xfffffe0125e7ca60
panic() at panic+0x43/frame 0xfffffe0125e7cac0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe0125e7cb20
calltrap() at calltrap+0x8/frame 0xfffffe0125e7cb20
--- trap 0x9, rip = 0xffffffff811464b2, rsp = 0xfffffe0125e7cbf0, rbp = 0xfffffe0125e7cc20 ---
pmap_try_insert_pv_entry() at pmap_try_insert_pv_entry+0xc2/frame 0xfffffe0125e7cc20
pmap_copy() at pmap_copy+0x570/frame 0xfffffe0125e7ccc0
vmspace_fork() at vmspace_fork+0xca0/frame 0xfffffe0125e7cd40
fork1() at fork1+0x428/frame 0xfffffe0125e7cda0
sys_fork() at sys_fork+0x54/frame 0xfffffe0125e7ce00
amd64_syscall() at amd64_syscall+0x10c/frame 0xfffffe0125e7cf30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0125e7cf30
--- syscall (0, FreeBSD ELF64, syscall), rip = 0x82562adca, rsp = 0x82112bce8, rbp = 0x82112bd40 ---
KDB: enter: panic
panic.txt0600003014644457534  7151 ustarrootwheelgeneral protection faultversion.txt0600007514644457534  7555 ustarrootwheelFreeBSD 13.2-RELEASE-p11 stable/24.1-n255023-99a14409566 SMP


/var/crash/textdump.tar.0:

ddb.txt06000014000014644457534  7112 ustarrootwheeldb:0:kdb.enter.default>  run lockinfo
db:1:lockinfo> show locks
No such command; use "help" to list available commands
db:1:lockinfo>  show alllocks
No such command; use "help" to list available commands
db:1:lockinfo>  show lockedvnods
Locked vnodes
db:0:kdb.enter.default>  show pcpu
cpuid        = 15
dynamic pcpu = 0xfffffe009fce1300
curthread    = 0xfffffe011fff8720: pid 69240 tid 106457 critnest 1 "python3.11"
curpcb       = 0xfffffe011fff8c30
fpcurthread  = 0xfffffe011fff8720: pid 69240 "python3.11"
idlethread   = 0xfffffe00c7262000: tid 100018 "idle: cpu15"
self         = 0xffffffff82c1f000
curpmap      = 0xfffffe0124667128
tssp         = 0xffffffff82c1f384
rsp0         = 0xfffffe0125e7d000
kcr3         = 0x80000002326954e8
ucr3         = 0x8000000240877ce8
scr3         = 0x240877ce8
gs32p        = 0xffffffff82c1f404
ldt          = 0xffffffff82c1f444
tss          = 0xffffffff82c1f434
curvnet      = 0
db:0:kdb.enter.default>  bt
Tracing pid 69240 tid 106457 td 0xfffffe011fff8720
kdb_enter() at kdb_enter+0x37/frame 0xfffffe0125e7ca10
vpanic() at vpanic+0x182/frame 0xfffffe0125e7ca60
panic() at panic+0x43/frame 0xfffffe0125e7cac0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe0125e7cb20
calltrap() at calltrap+0x8/frame 0xfffffe0125e7cb20
--- trap 0x9, rip = 0xffffffff811464b2, rsp = 0xfffffe0125e7cbf0, rbp = 0xfffffe0125e7cc20 ---
pmap_try_insert_pv_entry() at pmap_try_insert_pv_entry+0xc2/frame 0xfffffe0125e7cc20
pmap_copy() at pmap_copy+0x570/frame 0xfffffe0125e7ccc0
vmspace_fork() at vmspace_fork+0xca0/frame 0xfffffe0125e7cd40
fork1() at fork1+0x428/frame 0xfffffe0125e7cda0
sys_fork() at sys_fork+0x54/frame 0xfffffe0125e7ce00
amd64_syscall() at amd64_syscall+0x10c/frame 0xfffffe0125e7cf30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0125e7cf30
--- syscall (0, FreeBSD ELF64, syscall), rip = 0x82562adca, rsp = 0x82112bce8, rbp = 0x82112bd40 ---
db:0:kdb.enter.default>  ps


Liebe Grüße

Welches Modell des MS-01? Ich hoffe, nicht der 13900H? Intel hat mit den CPUs der 13. und 14. Generation massive Probleme und bekommt sie auch mit Microcode-Updates nicht in den Griff. Gerüchteweise liegt es an den E-Cores, kannst die ggf. ja testweise mal deaktivieren.

Ich hatte den MS-01 mit 12900H im Einsatz und keinerlei Probleme.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Sieht zumindest sehr unspezifisch aus in pmap_try_insert_pv_entry() beim Speicherschieben umgefallen...


Grüsse
Franco

Ich wollte mich nochmal zurückmelden. Danke für eure Hinweise. Ja, leider habe ich die Version mit dem 13900 :( Ich habe jetzt testeshalber was im BIOS mit den E-Cores eingestellt. Bisher läuft die Firewall seit 6 Tagen. Mal abwarten...

Wenn es beim Speicherschieben auftritt, kann es auch defektes RAM sein, liest man bei DDR5-SODIMMs oft.

Auf jeden Fall solltest Du die Microcode-Updates anwenden, Anleitung in der Tutorial-Sektion.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+