Intermittent Linux kernel oops only under heavy memory pressure despite MemTest86 passing

Environment

Workstation: AMD Ryzen 7 5800X with 32GB DDR4 (2x16GB) in dual-channel, running Ubuntu 22.04 with stock kernel 5.15; MemTest86 completed multiple passes with no errors; VMs and containerized workloads run concurrently.

Symptoms

Under sustained memory- and I/O-heavy workloads (large builds and simultaneous VM workloads), the system intermittently experiences kernel oops/panics referencing 'NULL pointer dereference' in kernel slab allocator code and OOM-like stack traces. Reboots recover system. Issue does not occur under light desktop use or when running memory stress tests that allocate but do not exercise specific kernel paths.

Observations

dmesg logs after reboot contain oops backtraces pointing to kmalloc/scheduler code paths and occasionally show 'uncorrectable ECC' messages in some traces on systems with non-ECC RAM (meaning message is synthetic). MemTest86 passes; swapping RAM sticks between DIMM slots did not change frequency of oops. Using an older kernel (5.13) reduced occurrence rate but did not eliminate it. CPU and motherboard temperatures within spec; BIOS is latest stable release with default settings (XMP disabled).

Already attempted

Updated BIOS to latest stable, swapped DIMMs into alternate slots, tested each stick individually under MemTest86 (no errors), tried different kernel versions (5.13, 5.15), and disabled performance‑boosting BIOS options (PBO/auto overclocking). Observed oops less frequently with older kernel, suggesting a possible kernel regression or a timing-sensitive hardware interaction.

Question

Given passing MemTest86 but kernel oops under heavy Linux memory pressure, what diagnostic sequence will help determine whether this is a kernel bug, microcode/CPU erratum, or a subtle memory subsystem issue (training/IMC), and what non-destructive mitigations should I try first?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

A kernel regression or bug in the memory allocator or a driver exposing a null pointer under certain concurrency patterns. 85%

CPU microcode or chipset erratum triggered by specific memory access patterns; new BIOS/microcode may be needed. 65%

Third-party kernel module or driver (e.g., for VM acceleration or proprietary device) causing instability under load. 55%

Summary

MemTest86 checks raw memory patterns but may not exercise platform-specific memory controller timing, high concurrency, or kernel paths that expose CPU/microcode or chipset issues. The reduction of frequency with an older kernel points toward a kernel regression or a changed scheduler/memory allocator behavior that stresses the platform differently. BIOS/firmware microcode or memory training issues can produce similar intermittent faults that only appear under complex real-world workloads.

Suggested Fixes

Diagnostic step 1

Collect reproducible test case and kernel oops logs (enable persistent journal, copy /var/crash and dmesg output). Install kdump/crash to capture vmcore for post-mortem analysis.

Diagnostic step 2

Boot with a few kernel command line options to narrow causes: try 'nohz=off', 'slub_debug=FZ', 'threadirqs', or boot with a distribution kernel build (not custom) to compare behavior; check if issue reproduces with a mainline stable kernel.

Diagnostic step 3

Test with latest CPU microcode updates (apply vendor microcode package) or try rolling back microcode/BIOS if a recent firmware update coincides with regressions; disable aggressive power/performance BIOS options (PBO, XMP) while testing.