Warrentheo
-
Posts
311 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Warrentheo
-
-
Most likely you tried to just flip it in the VM settings, but the change is too much for the WebGUI or manually editing the VM's XML... What you do is just create a new VM, but point it at all the existing image files, that will get all the sub devices sorted out correctly... Be careful doing this though, when the new one is working and you delete the old one, it will try and delete the "old" images files at the same time... One more reason to make sure your backups are up to date... When you are all done, you can move the image files around manually to make it look like normal...
-
Usually this is something filling up, like the SSD or something else... I had something like this when I had a repeated motherboard error filling up my Syslog file, which once it was full, the VM's would just lockup with no notification...
Most likely something similar is happening here...
If that doesn't help, we need diagnostics files, and the VM XML file...
-
That is good, but also normal even if not passing correctly, the real test is if the card still works after VM reboot...? If so, then you should finally be good... 👍
-
https://bit-tech.net/news/tech/graphics/amd-fixes-radeon-vii-uefi-gaffe-with-firmware-update/1/
QuoteAMD has confirmed that it is to fix a somewhat serious oversight in its recently-released Radeon VII graphics card family, which prevents systems with the card installed from using Secure Boot functionality, with a firmware update due to land imminently.
-
Switching from one to the other is like yanking the hard drive and putting it in a different motherboard... The i440fx is an ancient chipset for the Pentium 1+2 that never heard of a PCIe slot... Backups should definitely be done, and when you switch it and try to boot, it will take forever to reinstall every single driver on the system... While in my experience it usually works without issue, I won't be responsible if you skip the backups... I also would not expect a major improvement over the i440fx since even though it is having to run additional overhead, it is not that major... I mainly mention it because you and so restricted on the hardware you gave the VM... I have noticed other compatibility issues that still makes it worth it, and the only downside was in the past the q35 hadn't had as much testing... IMO there is no longer any reason for i440fx in windows anymore...
Q35-only features ● PCIe “goodies” – Extended configuration space (MMCFG) – PCIe native hotplug – Advanced Error Reporting (AER) – Alternative Routing-ID Interpretation (ARI) – Native Power Management – Function Level Reset (FLR) – Address Translation Services (ATS) ● AHCI storage controller ● vIOMMU emulation ● “Secure” Secure Boot -
Typically if you don't passthrough the VBIOS, the first time you boot the VM, it will work just fine, but rebooting the VM would require rebooting the host since there is no way to issue a reset to the video card from the VM without the VBIOS file, and you have to issue a reset the old fashioned way, by rebooting the motherboard it is plugged into...
Do you experience this? or does the card never work?
If it is always Error 43, there may be some hardware failure here interfering with it... Make sure the card works fine baremetal without UnRaid in the background... At this point we need to verify that is it not a hardware issue before we continue to troubleshoot software...
-
Trying to run 2 different computers on the same hardware at the same time will cause bottlenecks...
One thing I can say about your games you listed is that they are CPU bound, and all want at least 4 real cores...
Adding a H.T. Core can usually be guesstimated to add 1/4 of another core, so a 4 core and 4 H.T. system will usually have the speed of a 5 core system with no H.T.
You are basically running games that like 4 real cores or more on 2.5 cores... IMO this is the most likely cause of you issues... City SkyLines in particular will gobble up pretty much all the CPU power you throw at it...
Windows also can run on 4GB's of RAM, but will start pagefileing most of the ram right after boot, and so I would expect even windows to have issues with this, let alone running a game on it... (The recommended specs for Fortnite are 8GB's, though it does say the min spec is 4GB's)
One minor thing, you probably want to change your machine type from i440fx to Q35... But be careful, making that switch is like moving your hard drive to a new motherboard... Backup first, and first boot will take forever while it re-installs all drivers... This will eliminate some of the emulation overheard with running windows on a chip-set from the Pentium 1+2 era...
I think most of your issues boil down to needing to assign more hardware to the gaming side of your system... And the sad recommendation is to get a better system...
-
This is normally done with boot order, just set the hard drive to have a higher boot order than the ISO, then on first boot it will see an unformated disk, and boot the ISO, but the second time it will boot the disk...
There are other, more complicated options, like install "Virt-Manager" in the UnRaid app store that gives you something like the Host interface you are talking about with VirtualBox...
Or just use a second screen (Like a cell phone or tablet), and when the install is in the process of rebooting, fully shutdown the VM and edit it however you like...
There are many other options to solve this issue...
-
Yah, it can be an adventure... AMD cards can have special issues with CPU scheduling that unfortunately I am not familiar with...
4 minutes ago, Marshalleq said:Actually I dumped an EVGA 710 BIOS while I was at it.
Just so you know, the VBIOS dumping thing is because NVidia encrypted their VBIOS as well as the connection between the VBIOS and their drivers... However, they only started doing that on the GTX 10 series and the RTX... You should not need a VBIOS from a GTX710...
-
7 hours ago, Marshalleq said:
I just ran 3d passmark. The GPU runs OK at around 130FPS depending on the scenario, but what I notice is during the middle it will drop to less than 1 FPS. Also noticed, while typing the whole system pauses, then the typing catches up. There's something wrong with the way the VM is speaking to the host. So maybe it's not GPU passthrough at all.
This sort of thing sounds like a scheduling issue with the cores, most likely the UnRaid kernel and the Windows kernel both have access to the same cores, and some core is getting scheduled for double duty, thus locking up the other while it gets done... Make sure the VM and the Qemu emulator have their own cores...
-
Just so you know, the VBIOS passthrough was added for GTX 10 series and RTX cards because NVidia encrypted the VBIOS, as well as the connection between the drivers and the VBIOS... VBIOS passthrough is a workaround to fix this in Windows...
One way you can tell that this is not needed is you can edit your bios with an editor and make your own with your own fan curve and such, all of us 10 series people don't get those, and probably never will...
From what I understand there is a driver telling the card to do what it is doing, because if there was no driver yet, then the default settings in the VBIOS would still be in charge...
Some possible sources for drivers are:
UnRaid:
Edit your Syslinux config to include all the PCI ids for your card to use the VFIO driver, this prevents UnRaid/Linux from assigning any drivers of its own to it..
kernel /bzimage append vfio-pci.ids=10de:1b81,10de:10f0 initrd=/bzroot(Edit this to match all the device ids on your particular card, just don't add the PCIe slot to the list...)
This does make the card not work outside of a VM passthrough situation...
or
Windows:
You have not installed any fan control software for your card... If you have an EVGA card, download and install EVGA Precision XOC... Or you can install MSI afterburner on nearly any card (even EVGA if you like it better)... This should allow you to control the card like it would outside of a VM...
-
5 hours ago, steve1977 said:
Are you sure that your GPU pass-through is working? I had many issues how to get the pass-through working and - in some configurations - the VM even boots up well without any indication that it is not working.
I haven't tried Divsion 2, but other presumably similarly intense games like FF XV or FH 3 run without any issues.
The 1050ti is not the best performing of cards, but typically the way I understand it, you wont get the drivers to load in windows if you don't have a VBIOS for the NVidia card correctly passed through... The GTX 10 series and RTX series and up all encrypt the VBIOS as well and the connection between the VBIOS and their drivers... The VBIOS passthrough is a workaround to get this connection to work in a VM...
-
19 hours ago, Zer0Nin3r said:
Are you noticing any performance improvements after switching to Q35-3.0.0? I've been happy so far with the gaming performance on i440fx-3.0 running BFV, R6, and PUBG.
Maybe, I'll give it a try and report back.
Also, I was trying to search on the forum, but is it imperative that we don't pin anything to CPU 0/1? I'm running a Threadripper and I think I would get better performance if isolating VM's to a single chip versus spreading the workload of the VM across the Infinity Fabric.
- Does Unraid OS specifically like the first CPU pinning slot?
- Or it doesn't matter as long as you leave a single core & hyperthread open for Unraid?
===
I also, want to link back to another thread that discusses Q35 and gaming performance so we have a cross-reference here.
The performance issues is minimal, there is some additional overhead from the PCIe to PCI translation that occurs with PCIe passthrough on the i440fx, while the speed change barely reached the level of perceptable for me, the main reason for the fix was I have had several issues with compatibility... For a while, PUBG worked fine for me, then one day when they were adding in anti-cheat measures like battleye, it would fail battleye checks on my system and fail to load. I also had issues with the UWP game Sea of Theives just refusing to load... For me switching to Q35 gave me a minor but noticeable speed improvement, a noticeable reduction is minimum framerates in games (mico-stuttering), and suddenly games that refused to work or had issues no longer had those issues...
In the past the i440fx chipset was by far the one most polished by the Qemu community, and Q35 was just buggy or glitchy... From my admittedly limited experience Q35 is fully ready to replace the i440fx machine now, UnRaid already defaults to Q35 for the Linux based VM templates, and I believe there is no longer a reason for the Windows based ones to default to i440fx since even on Windows it no longer seems that it brings any benefit over Q35, and only seems to cause problems... Again, my opinion, and I am still looking for people that actually have issues with Q35...
Edit:
On you questions:
Quote- Does Unraid OS specifically like the first CPU pinning slot?
- Or it doesn't matter as long as you leave a single core & hyperthread open for Unraid?
Linux in general, and therefore UnRaid likes to have its primary core on Core 0... Even if you try and isolate Core 0 Linux will still use it anyway... You can isolate the Linux kernel from all the other cores, so you can even force all the UnRaid overhead and emulation down to just Core 0 if you felt the need...
There are 2 commands here that affect this sort of thing: The one for the Linux kernel itself is a config you put in your Syslinux config and looks like this:
kernel /bzimage append isolcpus=1-3,5-7 initrd=/bzrootThis would on my system leave Core 0, and its mirror Hyperthread, which on my system is Core 4, still available for anything the Linux kernel wants to do... Anything that wants to use those other "Isolated" cores has to specifically request them, since the kernel wont hand them out automatically any more...
There is a performance hit to running emulation, there is some housekeeping and cleanup needed when running in a VM, and those need to go somewhere... If you don't specifically specify where that work can be done, then if will go back to the Linux kernel to run this... If you have not done any isolation of cores or any other things to mitigate this, it will sometimes run with a higher priority on the cores that the VM (Windows) kernel wants to use... This will cause noticeable pauses, and minor bumps to your performance... We solve this by moving this overhead off the cores we assign to our VM by telling KVM/Qemu where to run this overhead at:
<cputune> ... ... <emulatorpin cpuset='0,4'/> </cputune>
Remember, you have both a Linux kernel, and the VM kernel (Windows) not talking directly to each other, and so will sometimes try and schedule the same CPU core to do two different things at once... So we trade some performance (some cores are now only used sometimes or even rarely) for a reduction in pauses and glitches (Cores are no longer double booked because we have 2 kernels fighting for the same cores)... Adding NUMA nodes and infinity fabric into this mix makes things even more complicated, and unfortunately I don't have an AMD chip to give advice on that... Getting a good balance between performance and VM lag is up to you and the application/game you are running...
Currently I am running without CPU isolation, but the emulator pinned outside of the cores assigned to the VM on my system... This means the emulator isn't causing issues in the VM, but other UnRaid processes potentially could, however I don't run many docker containers or other UnRaid processes, and so for me UnRaid acts mostly as storage manager...
-
1
-
Good luck with that, the USB3 type A port is literally just a USB2 type A port with 5 extra wires for more lanes and faster bandwidth... If you don't connect anything to those 5 extra wires, you literally have a USB2 port, so it should not matter which port you plug it into... Sounds like you have a fun one on your hands...
-
While I do get the impression that you do know what you are doing for the most part, there are a couple of things that pop out of that last statement... They do indeed make things like USB-C connectors on USB cables that only have enough wires to support USB2 connection speeds, if you have a USB 3.x port connected to a USB 3.x wire, the port shape becomes irrelevant... USB 3.x ports are fully backwards compatible, so the whole USB2 issue also becomes irrelevant... I have seen in the early days of USB 3.0 some USB 2.0 devices that had issues, but those were due to the crappy drivers on the original cards, and is basically a hardware issue or a driver issue with those specific ports...
I know this will sound like a put down, like recommending a "For Dummies" book to someone sounds like a put down, but I swear, this really helped me figure this stuff out since they made it surprisingly more complicated than it should have been with the bad naming that the USB spec has gone through over the years, I would recommend reading the Wiki page on the USB spec here: https://en.wikipedia.org/wiki/USB
Also this is a good read to see the kinds of issues you will face when you have issues like this: https://gizmodo.com/a-google-engineer-is-publicly-shaming-crappy-usb-c-cabl-1742719818
Beyond those it will just be trial and error to nail down exactly where the issue is, sometimes it is something wonky like one particular cable, but only when using a specific driver, or something equally mysterious... But I think you have a good start on figuring out your particular setup issues...
-
2 hours ago, jonathanm said:
Try going to device manager, highlight the computer name at the top of the list, select action, add legacy hardware, install the hardware that I manually select from the list.
When you initially install the driver, it may show up with an error, but when you reboot with the virtio it should work.
That does indeed install the driver in windows, but you also need those drivers outside of windows, before the boot procedure knows how to get to those drivers... I have only gotten that to work with a startup repair... It is the reason the VirtIO driver disk has a floppy image in the root of the iso (\virtio-win-0.1.160_amd64.vfd)... Back in the days of Windows XP, it was the only way to affect the boot drivers, at least in Windows 10 it lets you do it without digging out and plugging in your floppy drive...
-
On 2/5/2019 at 2:40 PM, darrenyorston said:
I know its a config issue. That's what I am trying to resolve. The working VM is Windows 10. So far I have tried Fedora and Linux Mint. Both distros see the output, just no audio. If I unplug the jack the input disappears from the sound options on Linux.
I have a Fiio USB DAC. Unfortunately it doesnt work on USB3.0 ports (known problem) and the only USB2.0 ports are via MB headers. Which is where the unRAID USB is currently attached. So I cant pass them through.
Some motherboards have multiple USB controllers, for instance mine has:
IOMMU group 3: [8086:a2af] 00:14.0 USB controller: Intel Corporation 200 Series/Z370 Chipset Family USB 3.0 xHCI Controller IOMMU group 15: [1b21:2142] 05:00.0 USB controller: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller IOMMU group 16: [1b21:2142] 06:00.0 USB controller: ASMedia Technology Inc. ASM2142 USB 3.1 Host ControllerAnd while for me, none of them can be passed through due to issues with my motherboard choice, yours may have multiple options, and one may be pass-through-able... Experiment with booting UnRaid on a different controller, and passing through the full controller known to be working...
Beyond that, I recommend getting a USB controller card and passing it through, or replacing the DAC with one that works on the ports you have...
-
This is the same as moving the boot drive from one computer to another, but this is really not an UnRaid issue, but rather just a "Windows Is Stupid About Drivers" issue...
It can be done, but the the ideal solution is to use the correct drivers during Windows install... I assume that is not an option here though...
If changing an existing install, make sure to backup the existing VM image file and XML file...
An overview of what is needed:
1. Boot the Windows ISO with the VM image file in question attached...
2. Tell it how to talk to the VM's image files...
Either loading the SCSI driver (vioscsi/win10/amd64/) or the SATA/VirtIO driver (viostor/win10/amd64/) from the Qemu Drivers disk)
For some reason, this can only be done by getting most of the way through the normal install process, but when it gets to the screen asking which drive to install to, it will be blank... This screen is the only one that has a "Load Driver" option hidden in the bottom left corner... While this was intended just to load storage drivers, you actually can install nearly any driver from here, as long as you load the storage driver last... You will know it worked when you can now see the image file partitions, and windows offers to install to one of them... Now this boot of the windows ISO knows how to talk to your VM's image file...
(p.s. I prefer the SCSI driver, since it is the only one that can enable Windows TRIM/Linux discard command to make it all the way down to a host SSD drive)
3. Click the "Red X" for the install, and tell it yes you want to cancel the install...
4. Go through the normal "Repair" to do a "Startup Repair"...
Process for this is as follows:
Boot off of the latest Windows 10 install ISO, and chose these options:
1. Click through all the options like a normal install, the options you pick here don't matter since we are not actually doing a Windows install...
...(Other setup windows will appear, click through till you get to the next one)...
...(Make sure to do a "Custom" install)...
...(We are finally where we can tell the Windows Install process about our storage drivers, click "Load Drivers")...
...(Load your driver)...
...(Click Next)...
...(This is the kind of thing we are looking for, Windows now knows how to talk to our drive 👍)...
...(Now kill the setup with the "Red X" 😣)...
...(Now that windows can even see our device, we can finally do a "Repair your computer")...
...(Chose "Troubleshoot")...
...(Then "Startup Repair")...
...(This will rebuild the Windows BCD files, hopefully this works for you)...
Unfortunately I have had a bunch of issues with this kind of thing over the years, this only works for me about 70% of the time... As I said above, the prefered method is to just set it correctly during Windows install... Beyond that, you have to do your own research into all the other ways and reasons Windows might not like you...
-
5 minutes ago, JQNE said:
I had to dump the ROM of my 1070ti and add on unraid boot flash drive this pci=noaer command to get stuff out of GPU.
After dumping rom, try adding that pci=noaer if it does not work without.
append pci=noaer (and other commands one space between every different command)
I also added pci=noaer to mine, but didn't know if it is normal for most people... Thought it was mostly my motherboard acting up...
For the record, you should not do this if there is any way not to, it is like fixing the wrench light in your car by cutting the wires to the light... Not the ideal solution, but I am still trying to fix the root issue that causes this issue for me... That said, I have been running with it on for several months now with no issue...
-
I use a GTX 1070 in Win10 Pro x64 VM, and I am not sure that the driver hacking option is really needed... I just used the SpaceInvader command to dump the ROM off my card, set it in the VM's XML file, and have had only minor issues since then (when installing drivers through GeForce Experience, halfway through the install the screen does some scary looking "snow" effects which makes the screen nearly unreadable usually, but works fine after it completes the install and I click the close button on the install then reboot the VM...)
First question is to make sure that the card works just fine when installed bare-metal (outside of UnRaid)...
If that is not the issue, make sure you are booting with UEFI (disable the "Compatibility Support Module" or CSM in your BIOS to make sure the old boot modes are disabled)
Then set UnRaid to boot with the card set to use the VFIO-PCI driver for your card...
append vfio-pci.ids=10de:1b81,10de:10f0 initrd=/bzroot(Make sure to change it for all the ID's on your card, including the audio devices)
This will prevent UnRaid from trying to steal the card for itself during boot...
Make sure the VM is set to use the OVMF bios, not the older SeaBios... This enables UEFI boot also in the VM, and GPU passthrough needs UEFI boot both host and VM to work correctly usually...
Make sure you are using the Q35 machine type (UnRaid defaults to the i440fx for some reason, which is the chipset from the ancient Pentium 1+2 that never heard of a PCIe slot...)
Use a good ROM for the card (preferably one from the card itself)... It is possible to download them from somewhere else, but there could be a version mismatch between the one you download and the one on the card itself, causing problems... There are also other possible issues with not getting the one from the card itself (file being twice as big as it is supposed to be, or filled with garbage and other issues)
I don't think that driver manipulation should really be needed, since if you are getting to the point where you need to do that, it means that you wern't successful in hiding the VM from the GeForce Driver install, and need to check the steps above...
QuoteEdit: This is all needed because Nvidia encrypted their VBIOS files as well as the connection between their VBIOS and their drivers starting in the GTX 10 and RTX series... The GTX 9 series and below don't have this "feature"... This was done for several reasons (HDCP, prevent AMD from reverse engineering their VBIOS, keep customers from modifying their cards to be better than more expensive cards, and others...) Passing through a good VBIOS lets the drivers complete this connection, and therefore removes the need to manually modify the driver side to fix the same issue... I don't believe all this is needed on an AMD card, because they don't care if Nvidia reverse engineers their VBIOS...
Once you get into windows itself and get the drivers to install with no error, there is a tool to help with the "message signaled interrupt" or MSI setting for the card, which is a much faster way of talking to the card than having to put everything through the CPU... The attached tool will help with audio issues and other things with the card, and needs to be run after every driver install or upgrade...
-
2
-
-
16 hours ago, itimpi said:
One thing to be aware of with vdisks is that normally they are set up as ‘sparse’ files. This means that disk space is not actually given to the file on the physical drive for parts that are not used. This means the space used on disk can be less than the the notional size of the vdisk file. As the VM runs it can write to unused parts of the vdisk that will cause extra space on the physical drive to be used. If the physical disk runs out of space during this process the VM can stop running correctly.
While you can manually sparse-ify these files with this command:
fallocate -d <filenamegoeshere>
which lets you "Dig" all the zeros out of a file... A better option would be to change the driver KVM/Qemu uses to be the SCSI driver, then set the the "Discard" option for the drive manually in the VM XML like this:
<disk type='file' device='disk'> <driver name='qemu' type='raw' discard='unmap'/> <source file='/mnt/user/domains/<imagefilenamegoeshere>'/> <target dev='sda' bus='scsi'/> </disk>
This lets the VM's TRIM command get passed to the host, and therefor make it all the way down to the real drive... This lets KVM/Qemu automatically manage the image file sparseness for you... Obviously much more useful if you are storing it on an SSD, since constantly changing the VM's image file size would murder speed on an HDD...
If you are running on a HDD, it is recommended that you leave these files fully allocated so that things like defrag continue to work correctly...
Edit: changing the driver that Windows uses to talk to the boot drive can be problematic, and is best set during windows install... It is possible to change afterward, but make sure to do backups of both the image file, and the VM XML before you try it...
-
The easiest way to guarantee solve this, passthrough a full USB controller card... Solve all kinds of weird devices not being fully passed through... Some motherboard USB cards can be passed, but none of the 3 on my Asus board could be, so your mileage may vary...
-
Have you watched the video by SpaceInvaderOne on nVidia passthrough?
-
1
-
-
If the device is known to be successfully passed through with any other VM, and you know that the new VM has the same passthrough settings, then it becomes a config issue for the new VM... Only thing I can say is make sure that is setup the same was as the one known to be working...
What I can say is that a lot of motherboards have minor issues with trying to passthrough the onboard audio... And while it is possible, I just passed through a USB card, and use a USB soundcard with it... That just avoids most of the minor issues with trying to use the onboard audio... For me that was easy, since I like aftermarket headphones anyway, and it may work just fine with some tweaking... Up to you...
PCIe USB3 Cards Passthrough help
in VM Engine (KVM)
Posted · Edited by Warrentheo
This may also be caused by not having your motherboard BIOS setup correctly... Make sure that you disable "Compatibility" boot modes in your BIOS, on my asus board this is called "CSM"... This will force UnRaid to boot UEFI, so make sure you turn on UEFI boot on the UnRaid flash settings before you do that...
Also make sure that the IOMMU groups are working correctly on your system, Intel VT-d or the AMD version on your board...
If it is not either of those, you may have gotten a cheap card that doesn't acknowledge the reset signal that the VM sends it, thus requiring the reset sent from the host motherboard to be able to connect to a VM again...