Summary: | panic: NULL dereference inside __mtx_lock_sleep() | ||
---|---|---|---|
Product: | Base System | Reporter: | Eugene Grosbein <eugen> |
Component: | kern | Assignee: | Eugene Grosbein <eugen> |
Status: | Closed FIXED | ||
Severity: | Affects Only Me | CC: | chris, hselasky, kib, net |
Priority: | --- | Keywords: | crash, needs-qa |
Version: | 11.3-STABLE | Flags: | koobs:
mfc-stable12?
koobs: mfc-stable11? |
Hardware: | amd64 | ||
OS: | Any |
Description
Eugene Grosbein
2020-03-10 01:05:28 UTC
The CPU is two-core Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, if it matters. Also, this system does not clear RAM between reboots, so dmesg buffer survives panic and saved to the log after reboot: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0x3b8 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80b024ad stack pointer = 0x28:0xfffffe022b5ed720 frame pointer = 0x28:0xfffffe022b5ed7a0 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock (0)) trap number = 12 panic: page fault cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff803b4bbb = db_trace_self_wrapper+0x2b/frame 0xfffffe022b5ed3d0 vpanic() at 0xffffffff80b2253e = vpanic+0x17e/frame 0xfffffe022b5ed430 panic() at 0xffffffff80b223b3 = panic+0x43/frame 0xfffffe022b5ed490 trap_pfault() at 0xffffffff80fb8d00 = trap_pfault/frame 0xfffffe022b5ed4e0 trap_pfault() at 0xffffffff80fb8d49 = trap_pfault+0x49/frame 0xfffffe022b5ed540 trap() at 0xffffffff80fb83dd = trap+0x29d/frame 0xfffffe022b5ed650 calltrap() at 0xffffffff80f979e3 = calltrap+0x8/frame 0xfffffe022b5ed650 --- trap 0xc, rip = 0xffffffff80b024ad, rsp = 0xfffffe022b5ed720, rbp = 0xfffffe022b5ed7a0 --- __mtx_lock_sleep() at 0xffffffff80b024ad = __mtx_lock_sleep+0xbd/frame 0xfffffe022b5ed7a0 ipreass_slowtimo() at 0xffffffff80ca1078 = ipreass_slowtimo+0x28/frame 0xfffffe022b5ed7e0 pfslowtimo() at 0xffffffff80baa504 = pfslowtimo+0x54/frame 0xfffffe022b5ed810 softclock_call_cc() at 0xffffffff80b3acbf = softclock_call_cc+0x14f/frame 0xfffffe022b5ed8c0 softclock() at 0xffffffff80b3b1b9 = softclock+0x79/frame 0xfffffe022b5ed8e0 intr_event_execute_handlers() at 0xffffffff80ae7119 = intr_event_execute_handlers+0xe9/frame 0xfffffe022b5ed920 ithread_loop() at 0xffffffff80ae7807 = ithread_loop+0xe7/frame 0xfffffe022b5ed970 fork_exit() at 0xffffffff80ae44c3 = fork_exit+0x83/frame 0xfffffe022b5ed9b0 fork_trampoline() at 0xffffffff80f989fe = fork_trampoline+0xe/frame 0xfffffe022b5ed9b0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic Uptime: 24d16h23m51s The lockname should always be valid for the mutex. Else this may be a memory corruption issue. Do you know if the router was about to reboot when this happened? (In reply to Hans Petter Selasky from comment #4) Sorry for late reply, I've missed your question. AFAIR, the router was not rebooting. However, it has USB-based Wifi card run0 in station mode with unstable connection, so corresponding run0/wlanX kernel objects could be destroyed/re-created any moment. Believed to be fixed with MFC r359746 to stable/11 as the problem did not repeat since then. The hardware now runs stable/12 that did not reproduce the problem, too. |