Kernel panics after upgrade to R1

Started by computeralex92, July 16, 2024, 08:21:29 PM

Previous topic - Next topic
>>> widgets are not resizable ?

They are if you unlock the dashboard in the upper right corner

I tried that, not working vertically. I wanna see full service list so I can extend it bit down, hit refresh and it's back to before.

Can we keep this thread to the core of the subject?

Let's bisect this then if BETA is good. I'll have a new kernel in a bit.


Cheers,
Franco

Quote from: franco on July 17, 2024, 07:03:49 AM
Can we keep this thread to the core of the subject?

Let's bisect this then if BETA is good. I'll have a new kernel in a bit.


Cheers,
Franco

Until now no panic with the beta kernel...

> Until now no panic with the beta kernel...

Good, here is the next one:

# opnsense-update -zkr 24.7.b_15


Cheers,
Franco

Quote from: franco on July 17, 2024, 07:30:53 AM
> Until now no panic with the beta kernel...

Good, here is the next one:

# opnsense-update -zkr 24.7.b_15


Cheers,
Franco

So far no panic after reboot:

FreeBSD OPNsense.localdomain 14.1-RELEASE-p1 FreeBSD 14.1-RELEASE-p1 n267732-007d9fa5c015 SMP amd64

Ok, second confirmation would be nice. This is going to be a weird one if it's in the later commits leading up to RC1.


Cheers,
Franco


After reboot, 24.7.b_15 crashed twice for me but then it's working fine so far. Submitted the problem, not sure if it's sent bc of the 2nd crash.

Ok guys I really have conflicting crash reports with different panics. If we screw up the bisect because our goal is "crash" we just produce heat and waste time. If you can send your crash reports on _15 so I can check...

Managed to get this for now...



<118>Root file system: zroot/ROOT/24.7.r1-b15Kernel
<118>Wed Jul 17 05:44:21 GMT 2024
<118>
<118>*** OPNsense.localdomain: OPNsense 24.7.r1 ***
<118>
...........................

kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 02
fault virtual address = 0x20
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80c1e520
stack pointer         = 0x28:0xfffffe0109632df0
frame pointer         = 0x28:0xfffffe0109632e00
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process = 7 (pf purge)
rdi: 0000000000000000 rsi: 0000000000000000 rdx: fffff8000906a000
rcx: fffff8000906a000  r8: ffffffff827e0490  r9: 0000000000000014
rax: 0000000000000000 rbx: 0000000000000000 rbp: fffffe0109632e00
r10: fffff801c8cae840 r11: 000000007ffc94e4 r12: 0000000000000000
r13: fffff8000906a000 r14: 0000000000000000 r15: 0000000000016d25
trap number = 12
panic: page fault
cpuid = 1
time = 1721195385
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0109632ae0
vpanic() at vpanic+0x131/frame 0xfffffe0109632c10
panic() at panic+0x43/frame 0xfffffe0109632c70
trap_fatal() at trap_fatal+0x40b/frame 0xfffffe0109632cd0
trap_pfault() at trap_pfault+0x46/frame 0xfffffe0109632d20
calltrap() at calltrap+0x8/frame 0xfffffe0109632d20
--- trap 0xc, rip = 0xffffffff80c1e520, rsp = 0xfffffe0109632df0, rbp = 0xfffffe0109632e00 ---
turnstile_broadcast() at turnstile_broadcast+0x40/frame 0xfffffe0109632e00
__mtx_unlock_sleep() at __mtx_unlock_sleep+0x73/frame 0xfffffe0109632e30
pf_unlink_state() at pf_unlink_state+0x338/frame 0xfffffe0109632e70
pf_purge_expired_states() at pf_purge_expired_states+0x178/frame 0xfffffe0109632ec0
pf_purge_thread() at pf_purge_thread+0x13b/frame 0xfffffe0109632ef0
fork_exit() at fork_exit+0x7f/frame 0xfffffe0109632f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0109632f30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

Ok great, next one is:

# opnsense-update -zkr 24.7.b_7

I'm joining the fun. Just had two of those crashes in a row after working for at least 20 hours straight. Can't say for _7 right now, but installed it too.


Cheers,
Franco

Testing b_7, uptime 20 minutes on one FW, but as I mentioned this crash seems random and not always immediately after boot.

Yep, the worst part is actually knowing it's "good" because the bug might just be hiding ;)


Cheers,
Franco