OpenWrt固件重启网络时出现Kernel Oops问题排查求助

Hey there, let's break down how to tackle this Kernel Oops issue you're hitting with your OpenWrt device running kernel 3.18. Since this is your first time dealing with kernel crashes, I'll walk through actionable troubleshooting directions and possible root causes based on the details you shared:

聚焦proc_register调用栈的线索 #

The Oops triggering at proc_register is a strong hint that the problem ties to how the igmp_hwnat driver interacts with the proc filesystem. Here are key checks:

• Verify the struct proc_dir_entry in your driver: Are there uninitialized pointers, out-of-bounds memory access, or references to already freed memory? For example, did you forget to set a pointer to NULL before using it, or reuse a memory block that was released during network restart?
• Check the proc node path validity: Does the parent directory for the proc node still exist when restarting the network? If the parent dir was destroyed during the restart process, calling proc_register on it will trigger a crash.
• Look for duplicate registration: Did the driver call proc_register again without first unregistering the node during network restart? This can cause conflicts that lead to an Oops.

深挖igmp_hwnat专属驱动的问题 #

Even though the driver registers successfully on initial load, network restart introduces a different execution context where resource management might fail:

• Check driver callbacks for network restart: Does OpenWrt's network restart script trigger any driver-specific callbacks? If the driver doesn't properly clean up resources (like memory buffers, hardware registers) before reinitializing, dirty state can cause crashes.
• Verify hardware state reset: Are IGMP/HW NAT-related hardware registers or memory buffers properly reset during network restart? Stale flags or leftover data could lead to invalid memory/hardware access.
• Inspect locking mechanisms: If proc_register or related operations aren't protected by proper locks, concurrent calls during network restart could create race conditions that trigger the Oops.

考虑内核3.18的特定特性 #

Kernel 3.18 is quite old, with known edge cases in the proc subsystem and driver compatibility:

• Check for relevant kernel patches: Are there any upstream patches for proc_register in 3.18 that fix similar Oops scenarios? For example, some older proc subsystem versions crashed when registering nodes to non-existent parent directories, and your kernel might lack that fix.
• Review OpenWrt's kernel customizations: OpenWrt applies network-specific patches to 3.18. Could these changes alter how network restart interacts with drivers, leading to unexpected behavior in igmp_hwnat?

适合新手的内核崩溃调试技巧 #

• Capture the full Oops log: Beyond the call stack, note the register values and fault address in the Oops output—these help pinpoint the exact problematic code line. If your device allows, enable CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_INFO in the kernel config, then compile a debug build; this will show line numbers in the call stack.
• Temporarily disable igmp_hwnat: If the Oops stops happening after disabling the driver, you can confirm the issue is driver-specific and focus your debugging there.
• Check dmesg logs pre/post restart: Look for warning messages related to the driver (like "proc entry already exists")—these are often precursors to a full crash.

内容的提问来源于stack exchange，提问作者PEJ