Just now, aterfax said:

IOMMU RMRR warning is probably a red herring.

I suspect you need to follow / attempt to avoid error 43 with the link I sent above:  https://mathiashueber.com/fighting-error-43-nvidia-gpu-virtual-machine/

Well I just now noticed its only giving that RMRR warning for the sound portion nvidia audio but dosnt everything have to be passed through in order to not get code 43

14 minutes ago, Tswitcher29 said:

Well I just now noticed its only giving that RMRR warning for the sound portion nvidia audio but dosnt everything have to be passed through in order to not get code 43

I still get an RMRR warning on a ethernet passthrough on my server- given it is working in the VM, I assume you are getting a red herring of a warning.

 

Edit: I suppose you can test by setting up a Ubuntu / linux VM and taking a look for the device.

Edited January 23, 20206 yr by aterfax

I have searched forum and have tried many different things still no luck I just tried what you link me first time still no luck trying something different again about to give up and get a AMD card lol

There are a number of things you can try for code 43, but give this a try:

 

4 hours ago, Tswitcher29 said:

Kinda rude not everyone has perfect grammar and i suck at it I'm sorry for that idk what's so hard to understand about what I said instead of making fun of my grammar how about you ask me questions to better understand what you need to help me 

tower-diagnostics-20200123-0733.zip 57.78 kB · 1 download

 

I never said anything about your poor grammar. I said

 

4 hours ago, 1812 said:

a lack of punctuation does not help your situation either.

 

 

So at this point, I'll follow your request and I'll  ask you questions to better understand what I need to help you: 1. Do you want this fixed? 2. Are you willing to go back and add punctuation to your post so it's not a gigantic run on, semi coherent sentence? and 3. Can you drop your attitude? You may attract more flies with manure than honey, but you end up smelling like it in the process.

 

3 hours ago, aterfax said:

IOMMU RMRR warning is probably a red herring.

 

You should read the top of the thread as it pertains to RMRR issues and proliants. It's not a red herring, it's a legitimate bios issue that prevents working hardware passthrough.

 

 

 

3 hours ago, 1812 said:

 

You should read the top of the thread as it pertains to RMRR issues and proliants. It's not a red herring, it's a legitimate bios issue that prevents working hardware passthrough.

 

You should read what I said then - "I still get an RMRR warning on a ethernet passthrough on my server" i.e. I get the warning on a device that is passing through correctly. Ergo, red herring.

16 minutes ago, aterfax said:

You should read what I said then - "I still get an RMRR warning on a ethernet passthrough on my server" i.e. I get the warning on a device that is passing through correctly. Ergo, red herring.

page 5 didn't show up for me at the time of my posting (most likely a stale window.) but either way thats news to me, except in a few cases when the device/address that triggers the RMRR error isn't passed through (like omitting sound from a gpu). seems you've got this all figured out then and should be able to fix his issue. carry on and I look forward to learning something.

Looks like this is related to the VM XML config:
 

-<hostdev type="pci" mode="subsystem" managed="yes">

<driver name="vfio"/>


-<source>

<address bus="0x04" function="0x0" slot="0x00" domain="0x0000"/>

</source>

<rom file="/boot/vbios/gtx 1060 dump.rom"/>

<address type="pci" bus="0x00" function="0x0" slot="0x05" domain="0x0000"/>

</hostdev>


-<hostdev type="pci" mode="subsystem" managed="yes">

<driver name="vfio"/>


-<source>

<address bus="0x04" function="0x1" slot="0x00" domain="0x0000"/>

</source>

<address type="pci" bus="0x00" function="0x0" slot="0x06" domain="0x0000"/>

</hostdev>

Assuming these are the GPU and GPU audio devices you have the audio in a different slot in the VM. These need to be matching the physical layout from the source hardware, i.e. same slot, different function.

Correct the second address to the same slot and one function higher i.e. :
 

<address type="pci" bus="0x00" function="0x1" slot="0x05" domain="0x0000"/>

Which will probably fix the issue.

See reasoning below:

 

This is assuming that the passthrough is actually working* and the VM can actually see the GPU hardware.

Edited January 23, 20206 yr by aterfax

UPDATE: Just uploaded 6.8.2 to GitHub.

I've just uploaded 6.8.3.

Enjoy <3

Don't get excited, an update on 6.9.

 

I'm currently looking, line by line in the kernel's source code trying to figure out how to patch it. I'm trying to find information mentioned by rafalz on the ProxMox forums at "https://forum.proxmox.com/threads/compile-proxmox-ve-with-patched-intel-iommu-driver-to-remove-rmrr-check.36374/post-313467" Who's got it working on a 5.X kernel.

 

If you want to help, please DM me.

 

An alternative is to downgrade your BIOS to something sub 2009ish but I don't feel that's a very good workaround.

update: i'm currently testing a "working" patched version of 6.9.0 beta 25

How did you get it patched? I've put my efforts on hold right now, was just confirmed to have COVID-19. Been too sick to look at it lol.

Sent from my SM-G975U using Tapatalk

20 minutes ago, AnnabellaRenee87 said:

How did you get it patched? I've put my efforts on hold right now, was just confirmed to have COVID-19. Been too sick to look at it lol.

Sent from my SM-G975U using Tapatalk
 

I sent you a message explaining how (different method) and with the bzimage

 

REST UP!

Hope you recovered well @AnnabellaRenee87. Did you guys get anywhere with the 6.9 patch? So frustrating that this is an issue at all.

I too would like to have an update on what the status is for the 6.9 patch. Hopefully @AnnabellaRenee87 has managed to recover well.

status is still pending. it looked like it was working, but was not. it's a little tricky to explain but compiling showed no errors and passthrough was intermittent for some undetermined reason. 

 

once 6.9 goes into RC phase we will then attempt to try again. this is because it may take a combination of 6.9 but using a more recent linux kernel. or not. we'll know more once we get there. if anyone wants to playground, then I recommend downloading the kernel compiling plugin as a start. in some ways it has expedited the process of working on it.

I'm gonna take another crack at it in a few days. When I was working on it last I ended up catching COVID-19.

Was dead for about 2 weeks, when I got sorta better work exploded, cats and dogs.....

Sorry.

Sent from my SM-G975U using Tapatalk

Hi.

I have just ordered new hardware to replace my HP Microserver Gen8.

To unstall this patch, do i just have to replace the bzimage file? or do i need to replace all the bz* files?

 

Thank you

2 hours ago, hjaltioj said:

Hi.

I have just ordered new hardware to replace my HP Microserver Gen8.

To unstall this patch, do i just have to replace the bzimage file? or do i need to replace all the bz* files?

 

Thank you

just the bz that you replaced only. Or you can upgrade to a newer Unraid version via the normal method and it will also work without the patch.

 

Thank you @1812, @AnnabellaRenee87, and @CHBMB for all your work on this.  I have a ProLiant ML350e Gen8 that I wanted to pass through a 1050ti for extra gaming PC.  I would never have gotten this far.  Thanks again for all the work!

Hi,

Just wondering if there has been any testing with RC1 and the new kernel?

Thanks 

 

 

9 hours ago, wardie72 said:

Hi,

Just wondering if there has been any testing with RC1 and the new kernel?

Thanks 

 

 

Hello

 

not yet. I'm going on holiday soon but should be able to start on it sometime around the 27th or so

 

 

Ok great, thanks.

 

I did have a look at compiling myself, but as I’ve never really been much of a Linux guy it’s too much of a curve to troubleshoot.

testing in progress..... ...   ..