Неизвестная причина NMI 20 и 30 на виртуальной машине

10

Я поднял консоль на виртуальной машине, которой я управляю сегодня, и меня встретили сообщения ядра:

[5912557.130943] Uhhuh. NMI received for unknown reason 20 on CPU 0.
[5912557.131115] Do you have a strange power saving mode enabled?
[5912557.131287] Dazed and confused, but trying to continue
[6064281.393568] Uhhuh. NMI received for unknown reason 30 on CPU 1.
[6064281.393888] Do you have a strange power saving mode enabled?
[6064281.394235] Dazed and confused, but trying to continue

Это лишь некоторые из них, 20 и 30 встречаются на CPU 0 и 1.

  • Виртуальная машина - это Debian Jessie, загрузка BIOS («Стандартный компьютер QEMU (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014»; ядро ​​3.16.0-4-amd64)
  • Hypervisor - это libvirt / KVM, работающая на тестировании Debian (в настоящее время Debian 4.7.0-1-amd64; qemu 1: 2.7 + dfsg-3).
  • Аппаратное обеспечение - Opteron 6344 на Supermicro H8SGL-F с ECC RAM с включенной очисткой .

Я не вижу сообщений об ошибках и предупреждениях NMI или EDAC на хосте.

Любая идея, что вызывает эти сообщения NMI на гостя? Они о чем беспокоятся?

(Может быть связано с NMI, полученным по неизвестной причине. 20 - У вас включен странный режим энергосбережения? Но это, кажется, голое железо).

derobert
источник
Интересно, поможет ли это перейти к ядру виртуальных машинnoapic apci=off
Rui F Ribeiro
@RuiFRibeiro Ну, в настоящее время виртуальная машина работает без каких-либо (очевидных) проблем. Он находится в производстве, поэтому я бы не стал перезагружаться, чтобы попробовать случайные варианты ядра, просто чтобы посмотреть. Это была бы другая история, если бы она помогла разработчику ядра отладить проблему и т. Д. (Плюс, это не так, как они часты - потребовалось бы время, чтобы быть уверенным.)
derobert
Я пытался выследить ту же проблему в течение некоторого времени. Вот некоторые данные, которые могут быть полезны: версия ядра хоста, версия qemu, использует ли виртуальная машина BIOS или загрузку UEFI, использует ли виртуальная машина i440fx или q35.
Майкл Хэмптон
@MichaelHampton запросил подробности, добавленные к вопросу.
Дероберт
У меня та же проблема, вот подробности (на самом деле очень похожие): ВМ - это Debian jessie (3.16.0-4-amd64) с BIOS 1.7.5-20140531_083030-gandalf (04/04/2014). Hypervisor - это libvirt / KVM в Debian jessie, но с резервным ядром (4.7.0-0.bpo.1-amd64). Аппаратное обеспечение гипервизора - два Opteron 6272 с ОЗУ ECC (материнская плата в настоящее время неизвестна, но, скорее всего, это Supermicro). Учитывая, что эти детали удивительно похожи на детали Дероберта, я не слишком удивлен, что столкнулся и с этой проблемой, но, надеюсь, они помогут.
Jvperrin

Ответы:

2

У меня была та же проблема с использованием аналогичной установки:

  1. Процессор AMD (хотя я видел сообщения об этой же проблеме с процессорами Intel, но ни один из моих гипервизоров, работающих на процессорах Intel, не имел этой проблемы, даже с включенным сквозным прохождением процессора).
  2. Debian, ядро ​​4.x на гипервизоре и guest (4.9.0-4-amd64 в моем случае на обоих).

Мое решение состояло в том, чтобы переключить мою гостевую виртуальную машину на использование эмулируемого ЦПУ QEMU, а не сквозной передачи. Это повлекло за собой удаление <cpu mode='host-passthrough'/>строки из файла определения гостя.

Обновление : я сделал дальнейшее исследование, и проблемные элементы были под clockэлементом:

<clock offset='utc'>
  <timer name='rtc' tickpolicy='catchup'/>
  <timer name='pit' tickpolicy='delay'/>
  <timer name='hpet' present='no'/>
</clock>

Реальным решением было удалить три <timer>элемента, после чего их <cpu mode='host-passthrough'/>можно было бы снова включить.

Для полноты я добавил аналогичный ответ на связанный вопрос .

mjturner
источник
Эти три элемента являются значениями по умолчанию, отключение их не должно делать абсолютно ничего и повторно добавлять их при сохранении.
Саймон Рихтер
1

Кажется, проблема в том, что конец прерывания не сообщается должным образом.

Для libvirt убедитесь, что eoiвключен:

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

В командной строке для KVM, что переводится как

-cpu …,+kvm_pv_eoi

Похоже, что это работает для нас -M q35, в том числе для хост-процессора и конфигурации по умолчанию (прерывания RTC ставятся в очередь, прерывания PIT отбрасываются, HPET недоступен).

Саймон Рихтер
источник
0

У меня была такая же проблема на Debian 9и Qemu 2.8.1(Debian 1:2.8+dfsg-6+deb9u5).
Я решил это, заменив модель видеокарты с virtioна cirrus(или вы можете попробовать использовать другую модель со qemuстраницы руководства ).

Олег Голованов
источник