Voydz
-
Posts
5 -
Joined
-
Last visited
Voydz's Achievements
Noob (1/14)
0
Reputation
-
Voydz changed their profile photo -
Hey there, I can confirm that this is a bit of a pain with MSI motherboards. On my old ASUS I could directly select the primary GPU. (This becomes especially interesting if you want to use a primary GPU on the secondary PCIe slot. As the primary slot is most likely the only one supporting 16x speed. I some rare cases a GPU could be bottlenecked a bit on slower ports as far as I did understand.) Currently on my MSI I am running with CSM DISABLED (full UEFI mode only, I don't know how its called exactly right now) which will require a GOP compatible card in the secondary PCIe slot as primary GPU. As far as I understood the motherboard firmware will check for a card in the highest order slots first and picks the first one it finds. This is nice as it leaves the one in the primary slot for passthrough. For now my system works flawlessly like this (besides the issue mentioned in my third update). best regards
-
UPDATE: I tried to diagnose further by connecting a display to the (otherwise headless) server. I naturally use a UEFI/GOP compatible GPU as a primary card for the unRAID OS to use and a secondary one to pass through. After rebooting with the display connected to the "primary GPU" it seems to do the trick now. Now I am even more confused as it feels like bad support on Motherboard/BIOS side of things. But this makes no sense to me as I can not remind that happening before the upgrade. The server was "reboot save". (I hope its okay just commenting as I further progress the issue, as I feel its the best way to keep it tidy.)
-
UPDATE: I noticed those errors in the vfio log, so I tried using the unRAID "Tools -> System Devices" page to reconfigure my vfio bindings. After that all warnings are gone but the problem persists. For good measure the diagnostics is in the attachments. prime-diagnostics-20210315-1013.zip
-
Hi there! There appears to be an issue with GPU passthrough. I had GPU passthorugh working on 6.9.0-rc2 fine, using the latest approach to vfio binding I could find (using /boot/config/vfio-pci.cfg). For some information about vfio setup, please have a look on the screenshots. Unfortunately, I can not provide much detail on how I setup the VM itself, because it was running for quite some time now and I never touched it. After upgrading to 6.9.1 I am able to launch the VM but I can not access it. My unRAID server logs are spammed with the following entries: ... Mar 15 09:15:56 Prime kernel: vfio-pci 0000:26:00.0: BAR 1: can't reserve [mem 0xc0000000-0xcfffffff 64bit pref] Mar 15 09:15:56 Prime kernel: vfio-pci 0000:26:00.0: BAR 1: can't reserve [mem 0xc0000000-0xcfffffff 64bit pref] Mar 15 09:15:56 Prime kernel: vfio-pci 0000:26:00.0: BAR 1: can't reserve [mem 0xc0000000-0xcfffffff 64bit pref] Mar 15 09:15:56 Prime kernel: vfio-pci 0000:26:00.0: BAR 1: can't reserve [mem 0xc0000000-0xcfffffff 64bit pref] Mar 15 09:15:56 Prime kernel: vfio-pci 0000:26:00.0: BAR 1: can't reserve [mem 0xc0000000-0xcfffffff 64bit pref] ... My VM outputs: ... 2021-03-15T08:15:56.564833Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2c0, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564842Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2c1, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564850Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2c2, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564859Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2c3, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564868Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2c4, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564876Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2c5, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564885Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2c6, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564894Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2c7, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564902Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2c8, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564911Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2c9, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564920Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2ca, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564936Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2cb, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564948Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2cc, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564958Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2cd, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564968Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2ce, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564978Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2cf, 0x0,1) failed: Device or resource busy 2021-03-15T08:15:56.564987Z qemu-system-x86_64: vfio_region_write(0000:26:00.0:region1+0xbd2d0, 0x0,1) failed: Device or resource busy ... Resource busy seems quite odd to me. I tried to search this issue first, but I can not find any hint, which made me believe that that issue has to be related to the unRAID update. Thanks for any help and your hard work on this! best regards prime-diagnostics-20210315-0921.zip
-
Voydz joined the community
-
I am interested in using unRAID in favor of my current freenas setup. A bummer that I am not able to create a boot flash drive since I am currently left with a single Catalina powered Mac. Are there updates on when we can expect the flash creator with Catalina?
