|
|
Line 19: |
Line 19: |
| </gallery> | | </gallery> |
|
| |
|
| I [[KVM_and_GPU_Passthrough_in_Details#Isolation_of_the_Guest_GPU|mentioned]] the kernel command <code>irqpool</code> as solution for this issue, but in my opinion and according to some other posts, provided in the references section, this setting is an actual solution for the problem <code>irq 44: nobody cared (try booting with the "irqpool" option); handlers: vfio_intx_handler; Disabling IRQ #44</code>, that appears at my system when booting a VM with GPU passthrough with a display attached to it, which was causing host system reboot. | | I was [[QEMU/KVM and GPU Passthrough in Details#Isolation of the Guest GPU|mentioned]] the kernel command <code>irqpool</code> as solution for this issue, but in my opinion and according to some other posts, provided in the references section, this setting is an actual solution for the problem <code>irq 44: nobody cared (try booting with the "irqpool" option); handlers: vfio_intx_handler; Disabling IRQ #44</code>, that appears at my system when booting a VM with GPU passthrough with a display attached to it, which was causing host system reboot. |
|
| |
|
| References: | | References: |
Revision as of 12:57, 2 September 2022
Guest GPU Audio Crackling and IRQ xx: Nobody Cared Fix
The solution of the issue Guest GPU HDMI Audio Crackling, Broken or Losing is well explained by Jonp at UNRAID Forums. In short we must try to enable the MSI – Message Signaled Interrupts option if the device support it. Here is a detailed step-by-step instruction how to do that.
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 1: Open Device Manager and from the View menu switch to Resources by type.
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 2: Expand the section Interrupt request (IRQ).
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 3: Find the problematic audio device and by the context menu choice Properties.
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 4: Within the Details tab witch to Property Device instance path.
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 5: In this particular case the Value is PCI\VEN_10DE&DEV_0E08&SUBSYS_102F10DE&REV_A1\4&29fcb422&0&0016. This is a relative path to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum in the Windows 10's registry.
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 6: Run Registry Editor as Administrator.
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 7: In the Registry Editor tool, paste Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum in the path line and hit Enter.
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 8: In Device Manager, use the context menu and Copy the Value of the target Device instance path.
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 9: In Registry Editor append one backslash to the path and Paste the Value.
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 10: In Registry Editor, navigate to \Device Parameters\Interrupt Management\MessageSignaledInterruptProperties.
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 11: Then choose Modify from the context menu the Value of the DWORD Key MSISupported (MSI – Message Signaled Interrupts).
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 12: Change the Value of the DWORD Key MSISupported to 1 [0x0..01].
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 13: Confirm the change of the DWORD Key MSISupported (MSI – Message Signaled Interrupts).
-
QEMU KVM Windows Guest Fix NVIDIA NVS 315 HDMI Audio Step 14: Reboot the guest Operating system.
I was mentioned the kernel command irqpool
as solution for this issue, but in my opinion and according to some other posts, provided in the references section, this setting is an actual solution for the problem irq 44: nobody cared (try booting with the "irqpool" option); handlers: vfio_intx_handler; Disabling IRQ #44
, that appears at my system when booting a VM with GPU passthrough with a display attached to it, which was causing host system reboot.
References: