Kernel Nmi Watchdog Bug Soft Lockup CPU

A Linux “watchdog: BUG: soft lockup” message means a CPU has spent too long in kernel code without allowing other tasks to run. It is a diagnostic warning, not proof that the processor is faulty. Start by saving the kernel log, checking recent changes and.

What the soft lockup warning actually means

The phrase “Kernel NMI Watchdog Bug Soft Lockup CPU” combines related terms that do not describe one specific defect. Linux has detectors for soft and hard lockups. The exact warning and the messages around it matter more than that search phrase.

During a soft lockup, the affected CPU may still be executing kernel instructions, but other tasks are not getting a chance to run on it. This differs from a hard lockup, where normal interrupts are also unable to run. On supported systems, the NMI watchdog helps detect hard lockups using non-maskable interrupts.

The Linux kernel watchdog documentation explains both detectors. A watchdog reports a lack of progress; it does not necessarily cause the underlying fault or repair it. Whether detection produces a warning or a kernel panic depends on configuration.

A lockup can leave applications stalled, make remote access unreliable or freeze the desktop. A crash or forced restart can also lose unsaved work. However, the warning alone does not establish that stored files are corrupted.

Preserve evidence before changing settings

If the machine remains responsive, save your work and collect logs before rebooting. Record when the problem happened and what the machine was doing: starting up, waking from sleep, running a virtual machine, transferring files or using a graphics application.

• Save the complete warning, including the CPU identifier, task name and call trace.
• Record the kernel release with uname -r, along with your Linux distribution and hardware model.
• Note recent kernel, driver, firmware, hardware or configuration changes.
• Keep nearby messages about graphics resets, storage timeouts, thermal events or hardware errors.

On systems using systemd, journalctl -k -b shows kernel messages from the current boot. After a restart, journalctl -k -b -1 requests the previous boot's kernel messages, provided that journal was retained. If it is unavailable, check your distribution's logging setup; an empty result does not prove that no warning occurred.

The task named in the warning identifies what was running when the detector reported the stall. Treat it as a lead, not a verdict. Likewise, a CPU number identifies a logical processor and is not, by itself, evidence that a physical core has failed.

Troubleshoot in a controlled sequence

1. Establish the pattern. Check whether the warning occurs during one repeatable activity or across unrelated workloads. Compare the first occurrence with your update and maintenance history. A repeatable trigger gives you a useful way to judge whether a change helps.

2. Check distribution-supported updates. Review available kernel and driver fixes through your distribution's normal update process. Keep a working boot option available. Installing an arbitrary upstream kernel can introduce extra variables and complicate support.

3. Compare with a previously working kernel. If the issue began immediately after an update, boot a previously installed, supported kernel where available. Repeat the same activity and record the outcome. A difference between kernels helps narrow the investigation, but does not identify the precise defect.

4. Investigate implicated drivers. Look for repeated driver or subsystem names in the call trace and surrounding errors. Use driver packages supported by your distribution or hardware vendor. Change one component at a time so you can tell which change affects the result.

5. Review firmware and configuration. Check the manufacturer's guidance for your exact machine or motherboard before updating BIOS or UEFI firmware. If you have enabled overclocking or undervolting, return those settings to supported defaults and retest.

6. Run targeted hardware checks. Use memory, storage and manufacturer diagnostics when logs or symptoms point towards those components. Check cooling and reported temperatures if failures coincide with sustained work. Record actual errors before deciding to replace parts.

7. Verify under the original conditions. Repeat the activity that triggered the warning, then inspect the kernel log again. Record the kernel, driver and configuration used for each attempt. One quiet boot is limited evidence if the original failure was intermittent.

Use the symptoms to choose the next check

Lockups during heavy work or inside a virtual machine

High CPU utilisation alone does not demonstrate a kernel lockup. Reducing a workload temporarily can help reveal a relationship, but it does not establish that the CPU needs upgrading. Check whether warnings coincide with memory pressure, storage delays or a particular application entering the kernel.

For a virtual machine, also examine the host at the same timestamp. Check resource contention and whether other guests were affected. Guest logs alone may not explain delays originating on the host.

Warnings alongside display freezes

A frozen desktop can make the whole machine appear unresponsive. If possible, check whether an existing remote connection still works and inspect logs for graphics driver errors. Record the GPU model and active Linux driver; lspci -nnk can help identify PCI graphics devices and their kernel drivers.

If you are identifying the same hardware from a Windows installation, the guide to using a CMD command for graphics card information covers that separate task. Linux driver troubleshooting still needs evidence from the affected Linux installation.

Suspected hardware failure

Repeated diagnostic errors, thermal warnings or failures across supported software configurations justify a closer hardware investigation. A soft lockup message by itself is insufficient reason to buy a processor.

If replacement becomes necessary on an older machine, a reference such as the Socket rPGA 989 CPU list can be a starting point for research. Confirm the exact motherboard, firmware, power and cooling requirements with the manufacturer before choosing a replacement. A socket name alone does not establish compatibility.

Keep watchdog detection useful

Disabling a watchdog or increasing its threshold can hide warnings without removing the condition that triggered them. Treat such changes as controlled diagnostic measures when recommended for your specific case. Record the original settings and restore them after testing.

If the problem persists, send your distribution or hardware support team the full log, hardware details, kernel release, reproduction steps and comparison results. For background on identifying components, browse the computer hardware guides.

Start with the most recent occurrence: save its complete kernel log and note the last system change before it happened.