snsumner

User Introduction & Context Problem DescriptionAfter upgrading from Unraid 7.2.4 to Unraid 7.3.x, a long-standing Windows 10 VM ("Casatunes") lost access to its passed-through Creative Sound Blaster audio hardware. In Windows Device Manager, the audio zones showed translucent icons with Code 45 (Device Not Connected). Reverting the entire server back to Unraid 7.2.4 instantly and completely resolved the issue, indicating a regression or structural driver change in the newer Linux Kernel / QEMU stack regarding legacy bridge hardware power states or interrupt handling. Hardware / IOMMU ContextThe card in question is a legacy split-chip architecture utilizing an onboard PCIe-to-PCI translation bridge: IOMMU Group 11: * [1102:7006] 01:00.0 PCI bridge: Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG PCIe to PCI Bridge [1102:0009] 02:00.0 Audio device: Creative Labs CA0110 [Sound Blaster X-Fi Xtreme Audio] Comprehensive Troubleshooting Log (Everything Attempted)1. Initial Storage/Motherboard Migration IssuesSymptom: Upgrading the VM template structure to modern defaults triggered an immediate Windows INACCESSIBLE_BOOT_DEVICE Blue Screen. Fix: Temporarily changed the Primary vDisk Bus from VirtIO to SATA. This bypassed the Q35 PCIe layout storage controller conflict and successfully allowed Windows 10 to boot to the desktop. 2. Driver & Basic Interrupt AdjustmentsVirtIO Tools: Repaired and validated the latest virtio-win-0.1.285-1.iso drivers inside the guest OS. Legacy Interrupts: Because the Creative card relies on older line interrupts (INTx) instead of modern MSI, we enabled "VFIO allow unsafe interrupt remapping" in the global Unraid VM settings. The card still reported Code 45. 3. XML Hardware Routing & Slot AllocationsAttempted to isolate the audio endpoint (02:00.0) manually within the XML by forcing it to alternate virtual slots: Attached directly to a clean virtual PCIe root port (bus='0x06'). Attached directly to a virtual PCIe-to-PCI Bridge (bus='0x05' slot='0x01'). Attached directly to the main virtual motherboard root complex (bus='0x00' slot='0x15'). Result: No change in Windows; device remained locked in a Code 45 state across all configurations. 4. Motherboard Chipset and Power State (D3) AdjustmentsSyslinux Power Tweaks: Suspecting the new kernel was force-sleeping the idle hardware endpoint, we appended vfio_pci.disable_idle_d3=1 to the Unraid flash boot lines. Machine Type Downgrades: Shifted the VM machine type sequentially backwards from pc-q35-10.2 down to pc-q35-7.2, pc-q35-6.2, and eventually completely reconstructed a flat PCI legacy layout using pc-i440fx-7.2 (including removing the itco watchdog device). Option ROM: Disabled the hardware option ROM bar in the XML (<rom bar='off'/>) to ensure the VM’s UEFI (pure-efi.fd) wasn't choking on the card's old 16-bit pre-boot code. Result: The VM booted flawlessly on every chipset version, but Windows remained completely blind to the device. 5. Attempts to Isolate the Onboard Hardware Bridge (01:00.0)Libvirt Block: Attempted passing the parent bridge chip via a standard <hostdev> block, which failed validation with: “XML error: Non-endpoint PCI devices cannot be assigned to guests.” QEMU Command Line Bypass: Attempted to use <qemu:commandline> to manually bind the physical bridge (01:00.0) at the root emulator level. This crashed the VM initialization completely with an Unraid core hook error: “Failed to bind device 01:00.0 to vfio-pci driver.” Host Power Management Override: Attempted removing the bridge ID from the VFIO stubbing list entirely while adding pcie_port_pm=off to the Syslinux profile. This was meant to force the host's native pcieport driver to keep the hardware bridge pathway physically powered on so the VM could talk to the audio endpoint behind it. Result: Followed by full cold AC electrical power cycles, this configuration still resulted in a persistent Code 45 error inside Windows. Diagnostic Notes for DevelopersEvery software, firmware, power regulation, and architectural topology flag available in KVM/QEMU was deployed to keep the hardware awake and visible. The fact that the card works instantly on Unraid 7.2.4 but is completely unreachable under Unraid 7.3.x strongly implies that the newer Linux kernel completely changes how physical PCIe-to-PCI bridge controllers drop power states, or how legacy INTx line interrupts are isolated when a single endpoint within a multi-chip bridge group is passed to a guest. unraid-mt-diagnostics-20260607-2240.zip unraid-mt-diagnostics-20260607-2250.zip

I tried using this vmdk but I'm unable to get it to work properly. I added my USB drive that has my key but when unRAID 6 boots up it says "No flash (-4)". It looks like the flash is showing up as the virtual disk instead of my USB drive. How did you configure this to work properly with the unraid license key?