ghost82

That card doesn't use any usb, it has 1 hdmi + 3 dp, no usb-c port. Anyway thanks for your efi, I'll give it a look tomorrow. However I'm quite confident the issue is with the bootloader, or with the monitor, or with the card, even if in windows vm everything is fine.

Still not sure why dp audio doesn't work for the sapphire nitro+ se version, even forcing the reference card vbios doesn't work (not a big issue since I'm using onboard hdef audio). This is not a problem for reference cards, that you seems to have.

Multifunction settings are wrong, you put multifunction on function 0, and use same bus, same slot but different function. <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/> </hostdev> However you have also this: vfio_err_notifier_handler(0000:06:00.0) Unrecoverable error detected Maybe you can find some more info into diagnostics/logs. Isolate and attach to vfio at boot also devices 02:00.0, 02:00.1, if they aren't attached. Once you fix the multifunction, check that the gpu doesn't attach to the host to efifb, otherwise edit your syslinux config and add video=efifb:off

New OVMF release Version: 202202 stable Release Date: 25/02/2022 OVMF_202202-Stable.zip

1. All of these may suggest a crappy vbios, dump your own and use it (if needed). 2. You didn't isolate gpu video and gpu audio, attach them to vfio at boot. 3. You gpu video may be assigned to efifb even if isolated, add video=efifb:off to your syslinux config 4. Multifunction is not set: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x43' slot='0x00' function='0x0'/> </source> <rom file='/mnt/user0/Greg/vbiosToBeReplacedWithYourOwn.rom'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x43' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev>

This can be solved by adding this to custom qemu args: <qemu:commandline> <qemu:arg value='-global'/> <qemu:arg value='ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off'/> </qemu:commandline> Mac os fails without this on machine type >=6.0 because in these versions acpi tables change and mac os doesn't like them. I have a 6900 xt too (sapphire nitro+ se), hdmi audio works, but not dp audio: https://github.com/acidanthera/bugtracker/issues/1924 Multifunction is wrong, change to this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x4f' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x4f' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x1'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x4f' slot='0x00' function='0x2'/> </source> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x2'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x4f' slot='0x00' function='0x3'/> </source> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x3'/> </hostdev> and I think your hdmi audio will start to work if you have lilu/weg/applealc

Sounds like a problem with previous video drivers, in fact you can see the grub menu, but it fails to display anything when it's trying to load video drivers. This could be if you are using qxl video drivers+vnc for the vm and you used a real gpu on bare installation. Is this the case? If it's so, you have 2 options: 1) Passthrough the same gpu to the vm in a multifunction device, so that the drivers are correctly loaded and you get a video output on the monitor 2) Delete gpu drivers inside the vm and use qxl+vnc You may also want to check that the uuid are correct in the fstab file (if you set it with uuid(s)) in the img clone.

Does it change anything if: 1- you remove the nvme passthrough (is this for storage)? 41:00.0 2- you lower the version of the machine from pc-i440fx-6.1 to pc-i440fx-5.1

The edit to vbios seems correct, what was your setup when running 6.9.2?What did you change (for sure the rom?, grabbed yesterday)?

sorry, didn't read this. What happens if you delete the vbios rom line?Does the vm fully boot? ..and sorry again, you already wrote it. Then the issue is with your vbios file. Can you grab it directly from your build?

Everything seems good in the log. did you install the latest drivers in the vm? With gpu passthrough, you may need to activate remote desktop INSIDE the vm (not vnc in unraid), connect to it from an external device and install latest nvidia drivers. What about the vbios rom file?Are you sure it's ok? About the append line in syslinux, this is obvious for you I think, but you applied it for "Unraid OS", so it applies when you boot unraid without gui, and no safe mode (gui and terminal).

Where is diagnostics?

Feb 21 21:49:28 Tower kernel: pci 0000:43:00.0: BAR 3: assigned to efifb Syslinux configuration, add in the append line: video=efifb:off Search in this section of the forum for more detailed explanation about this.

There's no "Unraid's xml", but there's libvirt (unraid is an interface for libvirt). I don't know and never used proxmox, but I can image it's the same, with its configuration options. Both proxmox and unraid are based on qemu and libvirt, libvirt being a sort of bridge to configure qemu vms (xml format). So the basic documents you want to refer to are that for libvirt (and qemu). You can run qemu vms from the command line terminal, qemu is a binary and you run it as a traditional binary, with options, parameters, etc. Or you can run libvirt vms from the command line with the "virsh" command. Most of the qemu commands/options are available in libvirt, so that options translate into xml format. When such options are not available directly in libvirt you use <qemu:commandline>. In the example above, in libvirt: <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='device.hostdev1.x-msix-relocation=bar2'/> </qemu:commandline> translates into qemu command line: ./qemubinary ...other options... -set device.hostdev1.x-msix-relocation=bar2

Probably in use by efifb, maybe before you were booting unraid in legacy and now you are booting in uefi? Search in this section of the forum, you will find a lot of discussions relating vfio_region_write, BAR X: can't reserve mem, video=efifb:off, and similar. It is, trust it

In that discussion, some user is reporting it working with the following mod, try to add custom qemu arg at the bottom of your xml, before </domain>. From your picture your pci passthrough should have the alias hostdev1. ... ... <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='device.hostdev1.x-msix-relocation=bar2'/> </qemu:commandline> </domain>

yes, there is no more virt-manager.

You probably passed to the vm only video and audio (26:00.0 and 26:00.1). These components are attached to vfio when you start the vm, but 26:00.2 and 26:00.3 are not, they are bound to their drivers in the host (different from vfio-pci). Since the gpu is a single device, this cannot operate correctly. Attach to vfio at boot the whole iommu group 16: all the devices should be attached to vfio at boot. Add to the vm xml also 26:00.2 and 26:00.3 for passthrough. Setup all these components in a multifunction device.

Yes, if you have doubts, first backup in different places your vdisks.img, that's all you need to restore a vm. You should have also the uuid code, but if you don't have the old xml you probably don't have it: this is important for windows activation, changing/replacing the uuid could mean reactivating windows. Steps you have to follow are just to create new vms (new templates) and point them to existing vdisks.

Thank you for the update, nice to see that you can pass only the wifi without the bluetototh: in some other oses, like mac os, you need to also pass the bluetooth part, that's why I suggested it, but this is not the case. Exact, firmware a0-63 is loaded, but from your previous post you tried to load it in previous tests without success. So, it was either an issue with corrupted dram in the device (no full power cycle) or because of this: Changing the iso means changing the kernel version and probably the iwlwifi version (firmware should be the same). Anyway, now you have all the inputs to fix it even if on updates it will stop working.

Apart a kernel panic during the last reboot during the update (solved only by rebooting the whole host), which was probably fixed 2 days ago in opencore (fix to msr 35h for ProvideCurrentCpuInfo, in case of -cpu=host) everything is running smooth. Update: Oh sorry, you were referring to ovmf: no, with this in my build, the update is able to reboot automatically, no force reboots needed (apart the kernel panic I described, but it's not ovmf fault).

This is a copy/paste of a private message I sent about how to correctly have an offline installation media: -- if you have access to mac os, the vm with vnc is ok, you can install the MDS application: https://twocanoes.com/products/mac/mac-deploy-stick/ free download is ok. This is recommended, since files will be downloaded directly from apple. 1. Run it 2. Select Download macOS 3. choose CustomerSeed as catalog 4. Select the os/version you want to download 5. click download and choose the target folder to save the image Note: no progress bar for download, just let the software there until a popup appears for the successful download (you need to download about 12 Gb) This will download a dmg file. Once you downloaded that image: 1. Run disk utility 2. Select File --> New image --> empty image 3. Give it a name in save as and name fields (let's call it "Monterey" in this example); Dimension: 16 GB; Format: Mac os extended (journaled); cryptography: none; Partitions: single, GUID; Image format: disc image read/write 4. save the empty image somewhere and it will be mounted automatically 5. mount the dmg image you downloaded with MDS and open the mounted image 6. right click on install mac os xxx, then show package content; navigate in Contents/Resources/ 7. run a terminal window 8. type "sudo " (sudo+space without quotes) and drag the file createinstallmedia in Contents/Resources/, type a space then add "--volume /Volumes/Monterey" (without quotes), something like: sudo /path/to/Install\ macOS\ Monterey.app/Contents/Resources/createinstallmedia --volume /Volumes/Monterey /Volumes/Monterey is the mounted empty image you created with disk utility. 9. press Enter, type your password and press again enter; files will be copied to the empty 16Gb image 10. Once finished, unmount both images 11. Rename Monterey.dmg to Monterey.img 12. Use Monterey.img as a sata installation disk in your xml (type='raw')

Rename .dmg to .img and add it to your xml: <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/path/to/installation/InstallationMedia.img'/> <target dev='hdd' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> </disk> unit number (3) and dev name (hdd) may change depending on your setup. If the img was created correctly opencore will see it.

Sure, but not with macinabox. The way macinabox works is to download a recovery image and from that download the os and perform an "online" installation. To have an offline installation you need to download the full mac os image and use the createinstallmedia to target a blank 16GB img file (there are a lot of tutorials around about how to do it), and simply add 3 disks to your vm settings, one for opencore (boot order=1), one for the mac os installation media and one for the target installation disk. Opencore will simply scan for available disks and it will find the mac os installation media.

Mount efi, edit /EFI/OC/config.plist with plain text editor. Search for Misc --> Boot --> Timeout Change value from 0 to 5 (change from disabled to x seconds to autoboot)