16

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?

Improve this question
1
  • 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.
    – Simon Richter
    Nov 27, 2019 at 10:12

5 Answers 5

Reset to default
7

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).

Improve this answer
3
  • 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.
    – Simon Richter
    Sep 17, 2020 at 12:59
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?).
Improve this answer
3

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.

Improve this answer
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'/>

Improve this answer
1

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.