19

I am using Debian GNU/Linux 7.8 (wheezy). While running my MATLAB program today, I got this message in terminal.

Message from syslogd@sas21 at Jul 18 16:40:49 ...
 kernel:[1747708.091929] Uhhuh. NMI received for unknown reason 20 on CPU 4.

Message from syslogd@sas21 at Jul 18 16:40:49 ...
 kernel:[1747708.091932] Do you have a strange power saving mode enabled?

Message from syslogd@sas21 at Jul 18 16:40:49 ...
 kernel:[1747708.091932] Dazed and confused, but trying to continue

I also remember hearing some beep sound in between.

What does this mean? And what should I do further?

2
  • 2
    I've received a good tip towards resolving this: this seems to appear only on guests that have rebooted since the last VM start, so apparently some VM state is not reset properly. Nov 27, 2019 at 10:12
  • 2
    @SimonRichter: No, this just happened to me on a laptop running Linux natively. It seems to be connected to resume after hibernation and in particular occurred in my case when I connected to my network player via Bluetooth. Oct 3, 2022 at 16:56

6 Answers 6

8

The problem seems to be that the End of Interrupt isn't communicated properly.

For libvirt, make sure eoi is enabled:

<domain>
  …
  <features>
    <apic eoi='on'/>
    …

On the command line for KVM that translates to

-cpu …,+kvm_pv_eoi

This seems to work for us with -M q35, host cpu passthrough and default config otherwise (RTC interrupts queued, PIT interrupts dropped, HPET unavailable).

6
  • From virt-install, the equivalent flag is --features eoi=on. Testing this in my own environment didn't seem to resolve it.
    – BMitch
    Jul 30, 2019 at 18:55
  • Thank you very much. This fixed it for me (I am always starting my VMs by command line, so I appended ,kvm_pv_eoi=on to -cpu host). However, I am still wondering why this happened. I am using KMV-based VMs since several years (since 2011 even on the same bare-metal host!), and it suddenly began in a freshly installed Debian buster guest, whereas all other guests continued working as usual and did not experience that problem.
    – Binarus
    Sep 17, 2020 at 9:15
  • @Binarus, check that it survives a reboot of the guest without restarting the VM -- that seems to make the problem reappear for some people. Sep 17, 2020 at 12:59
  • 1
    @Simon Richter: as your answer might also work for me, could you please give a more detailed instruction about how to enable eoi? Which file should I edit? What is the proper command? A link to some background information may also help. Thanks a lot! Jun 26, 2022 at 19:16
  • 1
    Thank you, Simon, for your prompt reply! Unfortunately, the solution does not work for me. There seems to be a different reason. It also only appears a short while after recovering from hibernate. So it seems to be related to the power saving mode. I'll check again the internet and if I don't find a proper solution I will open a new topic. Jun 26, 2022 at 23:38
4

I'm having the same issue since a couple of days on my KVM/QEMU host running Debian 8.6 with kernel 3.16.0-4-amd64. This is part of my log:

Jan 01 13:07:42 debbi3 kernel: Uhhuh. NMI received for unknown reason 20 on CPU 0.
Jan 01 13:07:42 debbi3 kernel: Do you have a strange power saving mode enabled?
Jan 01 13:07:42 debbi3 kernel: Dazed and confused, but trying to continue
Jan 02 10:48:58 debbi3 kernel: Uhhuh. NMI received for unknown reason 30 on CPU 0.
Jan 02 10:48:58 debbi3 kernel: Do you have a strange power saving mode enabled?
Jan 02 10:48:58 debbi3 kernel: Dazed and confused, but trying to continue

This started after installing BOINC (current task is Collatz Conjecture). I'm currently allowing BOINC to grab 99% of the CPU.

So, my guess as to the cause of these messages is that the CPU is being saturated and does not get enough time to handle (hardware) interrupts properly. In your particular case some other process or outside cause may be the culprit. YMMV.

3

This is a Non-Maskable Interupt (NMI) and is usually triggered by a hardware event on your system. In this case, it looks like the specific NMI is not configured and although it has received the NMI, it does not know what to do with it, so it just ignores it.

What should you do further?

  • If you just want to get rid of the message then you could try hiding it from the command line by configuring the syslogd.
  • If you want to fix the background issue then you need to triage what changed on the machine (e.g. new hardware/driver added?).
2

Maybe the CPU is getting too hot and generating a tiny errors, or screws up some instructions, but these noncritical errors can still be recovered by the kernel internally.

I received similar messages, but in my case I know that it is the GPU that is getting too warm. What I did was watching a high-resolution livestream on my PC. I happen to know that the GPUs are pretty old and weak, so this appeared in my error log:

Feb 15 10:39:14  kernel: [ 1708.477285] nouveau 0000:03:00.0: therm: temperature (86 C) went below the 'fanboost' threshold
Feb 15 10:39:16  kernel: [ 1710.452080] nouveau 0000:03:00.0: therm: temperature (90 C) hit the 'fanboost' threshold
Feb 15 10:39:21  kernel: [ 1714.926254] nouveau 0000:03:00.0: therm: temperature (86 C) went below the 'fanboost' threshold
Feb 15 10:39:23  kernel: [ 1717.261238] nouveau 0000:03:00.0: therm: temperature (90 C) hit the 'fanboost' threshold
Feb 15 10:39:23  kernel: [ 1717.535168] Uhhuh. NMI received for unknown reason 21 on CPU 0.
Feb 15 10:39:23  kernel: [ 1717.535172] Do you have a strange power saving mode enabled?
Feb 15 10:39:23  kernel: [ 1717.535173] Dazed and confused, but trying to continue
Feb 15 10:39:32  kernel: [ 1725.650454] nouveau 0000:03:00.0: therm: temperature (86 C) went below the 'fanboost' threshold
Feb 15 10:39:33  kernel: [ 1726.662936] nouveau 0000:03:00.0: therm: temperature (90 C) hit the 'fanboost' threshold
Feb 15 10:39:37  kernel: [ 1730.652335] nouveau 0000:03:00.0: therm: temperature (86 C) went below the 'fanboost' threshold

and many many more

1

I've seen this behaviour on a KVM virtual machine guest running Debian 9.0 (Stretch) using the PC-Q35 hardware type. The host is an AMD Turion.

Several solutions are suggested online (see, eg, this thread), including the following

  1. Switching to a QEMU emulated CPU rather than using CPU passthrough.
  2. Changing the KVM clock timer (adding <timer name='kvmclock' present='no'/> to the guest).
  3. Disabling ACPI support in the guest.

In my case, switching to a QEMU emulated CPU has fixed the problem. To do so I removed the following line from my VM XML file: <cpu mode='host-passthrough'/>

-1

I had the same problem on Debian 11 hypervisor after cloning Debian 10, 11 VMs from another hypervisor. It helped me to restart VMs and set CPU Model value Clear CPU Configuration.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .