I can’t remember ever getting a helpful response investigating these messages, e.g.: here.
Is your hardware old, e.g. roughly 20 years or more? I have a P4 with G98 NVidia that does this running Debian, accompanied by annoying speaker beeps, but TW and Leap don’t.
Define “legitimate”. Something in your hardware generated Non Maskable Interrupt without providing the definite reason for it (at least, the reason that kernel understands). The 21 is red herring - these are status bits in the same register where NMI reason is indicated and these bits are not related to NMI, at least if venor follows Intel specification.
Because only manufacturer(s) of the motherboard/CPU/BIOS can say anything helpful at all. Kernel has no idea what triggered this interrupt.
Uhhuh. NMI received for unknown reason 21 on CPU 11.: The kernel detected an NMI on CPU core 11. The “reason 21” is a hardware-specific code that the kernel doesn’t immediately recognize or have a standard handler for. This indicates an unexpected hardware event.
Do you have a strange power saving mode enabled?: This is a hint from the kernel developers. Sometimes, overly aggressive or buggy power-saving features in the BIOS/UEFI or operating system can cause unexpected behavior that manifests as an NMI. The kernel is essentially asking, “Is your system doing something weird with power management that might be causing this?”
Dazed and confused, but trying to continue: This is the kernel’s somewhat humorous way of saying it doesn’t fully understand why it received the NMI, but it’s attempting to recover and continue normal operation without crashing.
It is difficult to know what caused this … some ideas … and I do not know which may be relevant, but these are ideas as to where you could troubleshoot:
Check BIOS/UEFI Settings:
Power Management: Look for any advanced power-saving features like C-states (C1E, C3, C6, C7, etc.), EIST (Enhanced Intel SpeedStep Technology), or AMD Cool'n'Quiet. Try disabling some of the more aggressive ones temporarily to see if the NMIs stop.
Hardware Virtualization: (Less likely but possible) If you have Intel VT-x/VT-d or AMD-V/IOMMU enabled, ensure your BIOS/UEFI is up to date.
Firmware Updates: Check for and install the latest BIOS/UEFI firmware update for your motherboard. Manufacturers often fix hardware-related bugs in firmware.
Check for Overheating:
Ensure your CPU cooling is adequate. High temperatures can sometimes lead to instability and unexpected hardware behavior. Use tools like lm_sensors to monitor CPU temperatures.
Memory Test:
Run a thorough memory test (e.g., Memtest86+) to check for RAM errors. Faulty RAM can cause various obscure kernel issues, including NMIs.
CPU Health:
While less common, a failing CPU can also trigger NMIs. This is harder to diagnose without swapping components.
Look for Other dmesg Messages:
Are there any other error messages in dmesg around the same timestamp (3100.199630 seconds since boot) that might provide more context? Look for PCI errors, PCIe errors, or other hardware-related warnings.
Operating System Updates:
Ensure your openSUSE system is fully up to date (sudo zypper dup or sudo zypper update). Sometimes, kernel or driver updates can improve NMI handling or work around specific hardware quirks.
If these are isolated occurrences and the system remains stable, it might be a minor, infrequent glitch
But nothing from the 15.5 OSS-update repo, which I can confirm (as I have a virtual machine that runs stock 15.5 with the latest updates and only the Chrome repo added to it) has received zero updates since it was EOL.
Sorry, I should have made clear that I wasn’t questioning the idea that Leap 15.5 had reached End of Life. I was merely surprised that I was getting some updates. I realize that Chrome has it’s own/separate repository. I had not thought in so long of how vivaldi was obtained, that I had lost presence of mind that there is also a separate repository for vivaldi. In short, I have been way too busy for too long. My main concern was the way some of the supposed kernel messages were worded. There is a firewall in place here, and other security measures. I was worried about someone getting into the system, and playing around with the messages. If no who should know is concerned about the wording of the kernel messages, I’ll just say, thanks, and not pursue it any more.
Next time express yourself more clear. Just throwing in some lines without any real explanation why you are doing it will result in very different responses depending on the background of those who answer.
From the standpoint of the messages, developers sometimes have a sense of humor that shows up when unexpected error conditions come up. The source code is avaialble for the kernel, and a search for the message in the codebase would tell you they’re legit.
hendersj, I am a developer who has worked on various OS kernels, and I would never put some messages like that in a kernel. But thanks for the explanation. Somehow the operation of the openSUSE website is not as intuitive to me, as it once was. But I’ll see if I can track down the kernel source for Leap 15.5.
I’ve not done kernel development myself, but I have worked closely with developers who have done so in the past - such things were not uncommon in my experience, especially when the condition that the message was for was in code that logically should never execute.
(Anyone familiar with NetWare, for example, would be acquainted with the “Richard Kiel Memorial Abend”, which was just such a message; unfortunately, there was a condition that would cause that to happen even though it was never supposed to.)
You should be able to install the kernel source just by running zypper in kernel-source or by installing the kernel development pattern (devel_kernel).
It’s pretty normal for OSS to have all sorts of informal messages until a wave of corporatism takes hold and everyone has to work ‘like a professional.’ There isn’t even anything wrong with those messages.
And you don’t need to look to Suse’s website for the kernel source, you just need the kernel version, then go to git.kernel.org and look at the right release tag.
