ไม่ทราบสาเหตุ NMI 20 และ 30 บน VM

ฉันดึงคอนโซลขึ้นมาบนเครื่องเสมือนที่ฉันจัดการในวันนี้และได้รับการต้อนรับด้วยข้อความเคอร์เนล:

[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

VM คือ Debian Jessie, BIOS สำหรับบูต ("QEMU Standard PC (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
แหล่งที่มา

ฉันสงสัยว่าจะช่วยส่งผ่านเคอร์เนลของ VM ได้อย่างไรnoapic apci=off

— Rui F Ribeiro

@RuiFRibeiro ดีปัจจุบัน VM ทำงานได้โดยไม่มีปัญหาใด ๆ (ชัดเจน) มันกำลังอยู่ในการผลิตดังนั้นฉันจึงไม่อยากรีบูตเครื่องเพื่อลองใช้ตัวเลือกเคอร์เนลแบบสุ่มเพื่อดู จะเป็นเรื่องที่แตกต่างถ้ามันช่วยเคอร์เนลให้ดีบั๊กแก้ปัญหา ฯลฯ (นอกจากนี้ไม่ใช่ว่าพวกเขามักจะบ่อยครั้ง - มันต้องใช้เวลาสักครู่เพื่อให้แน่ใจ)

— derobert

ฉันพยายามติดตามปัญหาเดียวกันมาระยะหนึ่งแล้ว จุดข้อมูลบางอย่างที่อาจเป็นประโยชน์คือ: เวอร์ชันเคอร์เนลของโฮสต์, รุ่น qemu, ไม่ว่าจะเป็น VM ใช้ BIOS หรือการบูต UEFI ไม่ว่าจะเป็น VM จะใช้ i440fx หรือ q35

— Michael Hampton

@MichaelHampton ขอรายละเอียดเพิ่มเข้าไปในคำถาม

— Derobert

ฉันมีปัญหาเดียวกันนี่คือรายละเอียด (คล้ายจริงมาก): VM คือ Debian jessie (3.16.0-4-amd64) พร้อม BIOS 1.7.5-20140531_083030-gandalf (04/01/2014) Hypervisor เป็น libvirt / KVM บน Debian jessie แต่มีเคอร์เนล backported (4.7.0-0.bpo.1-amd64) ฮาร์ดแวร์ Hypervisor เป็นสอง Opteron 6272s โดยมี ECC RAM (ปัจจุบันไม่ทราบมาเธอร์บอร์ด แต่มีแนวโน้มว่า Supermicro บางชนิด) เนื่องจากรายละเอียดเหล่านี้คล้ายคลึงกับของ Derobert ฉันไม่แปลกใจเลยที่ฉันพบปัญหานี้เช่นกัน แต่หวังว่าพวกเขาจะช่วยได้

— jvperrin

คำตอบ:

ฉันมีปัญหาเดียวกันโดยใช้การตั้งค่าที่คล้ายกัน:

AMD CPU (แม้ว่าฉันเคยเห็นรายงานของปัญหาเดียวกันกับ Intel CPU แต่ไม่มี hypervisors ของฉันที่ทำงานบน Intel CPUs มีปัญหานี้แม้เปิดใช้งาน CPU passthrough)
Debian, เคอร์เนล 4.x บนไฮเปอร์ไวเซอร์และแขก (4.9.0-4-amd64 ในกรณีของฉันทั้งคู่)

ทางออกของฉันคือการเปลี่ยน VM แขกของฉันให้ใช้ซีพียูจำลอง QEMU แทนที่จะใช้ CPU passthrough สิ่งนี้เกี่ยวข้องกับการลบ<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
แหล่งที่มา

องค์ประกอบทั้งสามนี้เป็นค่าเริ่มต้นการปิดใช้งานไม่ควรทำอะไรเลยและเพิ่มลงในบันทึกอีกครั้ง

— Simon Richter

ปัญหาน่าจะเป็นที่สิ้นสุดการขัดจังหวะไม่ได้สื่อสารอย่างถูกต้อง

สำหรับ libvirt ตรวจสอบให้แน่ใจว่าeoiเปิดใช้งานแล้ว:

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

บนบรรทัดรับคำสั่งสำหรับ KVM ที่แปลเป็น

-cpu …,+kvm_pv_eoi

สิ่งนี้ดูเหมือนว่าจะทำงานกับเราด้วย-M q35โฮสต์ cpu passthrough และการกำหนดค่าเริ่มต้นเป็นอย่างอื่น (การขัดจังหวะ RTC เข้าคิวคิวการขัดจังหวะ PIT ลดลง HPET ไม่พร้อมใช้งาน)

— Simon Richter
แหล่งที่มา

ฉันมีปัญหาเดียวกันบนและDebian 9 ฉันแก้ไขได้โดยแทนที่ videocard model จากเป็น(หรือคุณสามารถลองใช้ model อื่นจากman page)Qemu 2.8.1(Debian 1:2.8+dfsg-6+deb9u5)
virtiocirrusqemu

— Oleg Golovanov
แหล่งที่มา