Jump to content

Skitals

Members
  • Content Count

    129
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Skitals

  1. Thanks for the update. I was just going to post an update and eat some crow, because my single-core benchmarks are similar to yours: I think 94% of bare metal performance is about what is expected, and that's the same as you posted in your original post. I'm very curious, with your changes, did that improve your cpu-z benchmark figure? I did play some gta5 and didn't see any slowdowns (playing >120fps at 1440p on 144hz freesync monitor). The game sounds notoriously cpu-bound. I tried doing some benchmarks but it seems ALL over the place. Especially for min fps. Some runs I would get 9 min fps... on bare metal. That doesn't translate on screen or in gameplay, I think it's literally the first few frames when the pass first starts. For my VM I am passing 10c/20t, so that might be giving me the edge.
  2. No, that isn't normal. What all have you changed in the bios? If you've messed with overclocking or any advanced settings I would highly recommend setting to factory defaults and making ONLY these changes: My initial guess is it is related to Global C-state Control. The factory default settings should be very stable (zero crashes). If you get crashes with default + the above settings, my next guess would be a hardware failure. What power supply are you using?
  3. The same as compiling any other linux kernel. The unraid specific patches you will find in /usr/src, including the kernel config file.
  4. There is more to it than the cpu settings. The machine type and what devices you are emulating and which drivers you are using could all be a factor. Are you using a vdisk, how many devices using virtio, which USB drivers are you using, etc. Also your motherboard bios... Which dictates your cpu microcode (agesa). Edit also what version of unraid including what kernel, what version of qemu, what version of virtio, etc. For reference I am using unraid 6.8.0-rc5, AMD AGESA 1.0.0.4 B, virtio drivers from virtio-win-0.1.160-1.iso. It's possible you have one device or one driver that is a bad actor. I will mess around with GTA5 and CPU-Z this weekend and let you know what I find.
  5. Bluetooth is connected to one of the USB controllers, it passes through with USB. On board audio should work with the kernel linked above.
  6. The Elite only has two x16 slots, and the second is limited to x4 speed. Keep that in mind if you are planning on passing through 2 gpus. I would recommend stepping up to the Ultra (which is what I did). The 1060 will work with a Mac OS VM, but you will be limited to high sierra. There is no nvidia support in modern mac os. Are you planning on running all these VMs at once?
  7. I'm glad it's working for you. On a couple of the 6.8 Release Candidates limetech did include v1 of the navi reset patch (this kernel has v2 which is improved but still not perfect). My understanding is it was causing issues with some hardware setups so they pulled it. I'm not sure what the rest of your hardware is, but it seems to work great in conjunction with amd x570 boards. The patch, as it's written, is all or nothing and applies to everyone with a navi gpu. Perhaps limetech would consider including the patch again if it was written to be exclusively opt-in with a kernel flag. I don't mind building my own kernel (and sharing), but I can understand why it would be frustrating to be dependent on someone like me to keep this updated.
  8. I haven't tested GTA5 (im installing it now to try), but I haven't had any performance issues in any games. I attached my redacted xml if you want to take a look, there is nothing special. I do not use CPU Isolation. The CPU pinning is the last 10 core+ht pairs. I do not pin anything to the first 2 cores. I am using the the default cpu freq governor. The only bios changes from factory settings are related to enabling virtualization, and setting xmp profile on ram. good_vm.txt
  9. Yes, this is more actively developed. You don't have to uninstall Dark Theme first, so feel free to try Theme Engine out. No need to restart. https://github.com/Skitals/unraid-theme-engine/
  10. Unraid needs a nic. It sounds like you need 3 total for what you are trying to do.
  11. If the NICs are in their own IOMMU groups you should be able to pass one but not the other.
  12. That seems like a really odd choice if you are concerned about pcie x16 slots, considering it only has two. Many/most boards have three... so sticking a dummy gpu in the 3rd slot is no loss. There is also the fact that unraid does not require its own gpu. You can passthrough your only/primary gpu just fine. That being said, there are some conveniences of giving unraid a gpu, so I agree with @testdasi's recommendation. I have a gigabyte x570 board and use a fanless gpu in slot 3 as my primary for unraid. I would highly recommend a gigabyte x570 board. It's the latest chipset and should get the most updates going forward. It works well with unraid/virtualization. gen4 pcie is a nice bonus and good future-proofing.
  13. Unraid 6.8(.1) Stable uses a linux 4.19 kernel. The 4.19 kernel was release in 2018. My recommendation is to stop using old software with new hardware.
  14. This is only for 6.8.0-rc5. To manually upgrade/downgrade, delete all the bz* files from the root of your usb drive (or rename them adding .bak to the end of the file name). Download rc5 zip here. Extract and copy the bz* files to your unraid usb drive. Download the kernel in the first post. Extract to your usb drive (overwriting bzimage, bzmodules, etc). All your settings are in /config (and maying /syslinux/syslinux.cfg) so back it up before mucking around.
  15. The fun never stops, I uploaded a new 6.8.0-rc5 kernel today that incorporates a bunch of goodies for this board. Brand new k10temp patches for Ryzen, and a fix for passing through onboard audio!
  16. Updated to add flr kernel patch. You can now pass through 1022:1487 [AMD] Starship/Matisse HD Audio Controller on x570 boards! I haven't tested, but you should also be able to pass through the cursed isolated 1022:149c [AMD] Matisse USB 3.0 Host Controller. I believe you are best off using that controller for your unraid usb/keyboard/mouse/ups and passing through the other two controllers, however.
  17. just updated the first post with a kernel that adds this. ymmv, it's untested.
  18. Just pushed out an update, it now shows if a device is currently bound to the vfio-pci driver. (Green orb indicates vfio-pci driver is in use)
  19. My group 24 looks like above. With BIND=0d:00.3 in vfio-pci.cfg, 0d:00.0 0d:00.1 and 0d:00.3 all show "Kernel driver in use: vfio-pci". But 03:08.0, which is in the same IOMMU group, shows "Kernel driver in use: pcieport". This is fine, probably preferred behavior, but it doesn't mesh with the documentation I've seen from @limetech: Is it more accurate to say that all functions of a device in the same IOMMU group will be bound? I realize with ideal/typical IOMMU groups that should mean the same thing, but is not in this case. Any clarification on the expected behavior would be much appreciated.
  20. For the X570 Taichi go to Advanced>AMD CBS>NBIO Common Options Make sure you have “IOMMU” set to “Enable” (Auto doesn’t work). Also make sure “Enable AER Cap.” is set to “Enable” Once you’ve set that an option called “ACS Enable” will show up, I left that set to “Auto”. After that’s done you’ll have the normal X570 IOMMU groupings. Source: https://forum.level1techs.com/t/x570-taichi-iommu-groups/145762/3?u=kiljacken
  21. I have had zero--absolutely zero--issues with the latest drivers and the above "features" disabled.
  22. When you load a saved (or included) theme, it switches to the "base theme" that theme uses (black, white, gray, azure, etc). All the included themes use "black" as the base theme. You can certainly use the plugin to design your own theme with azure as the "base theme." Since the layout is so different some of the options might not do exactly what you expect, but I know basic stuff like text color, link color, etc work fine. The rest would probably take a lot of "custom styling", like Raz has done with his black based themes.
  23. Basically what saarg said. Binding by id is perfect if it fits your use case. One downside of binding by address (this method) is it needs to be updated every time you change your pci hardware. A lot of boards these days have multiple devices with the same id, so binding by address is the only option. For example, every x570 board I've seen has 3 usb controllers with the same pci id. If you stub by id it stubs all 3, including the usb controller unraid needs. I would like to think this plugin is still useful if you use vfio-pci.ids since it shows reset functionality and which usb devices are on which usb controllers--info otherwise not available in the webgui.
  24. Also note that according to the documentation, when you bind to vfio using this method, ALL the devices in the IOMMU group get bound. So in your case, even though you only selected one item, everything in group 3 will be available exclusively to vfio. That means the USB controllers in that group won't work in unraid. That is why those other devices appear under Other PCI Devices. You should be able to pass them to your VM. I would pass them all together since they are all functions of the same PCI device. If you experience problems with onboard audio in your VM, that's probably why. You should pass all 5 devices to the VM.