Device is ineligible for IOMMU domain attach due to platform RMRR requirement

[viumden]

I have a Microserver Gen8, and tries to passthrough Nvidia GPU in PCI slot 1 under linux kernel 4.1.5, applied the advisory to PCI Slot1, still got the error message:

Device is ineligible for IOMMU domain attach due
to platform RMRR requirement. Contact your platform
vendor.

I think there is still something incompatible implementation in HP firmware. And there is just no valid solution from HP for several months.

[ralfE]

I get stuck with a Microserver Gen 8 with the same problem.

I applied the advisory (http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04781229&sp4ts.oid=5249566 ) to PCI Slot1 using the "conrep-stuff", still got the error message:

Device is ineligible for IOMMU domain attach due
to platform RMRR requirement. Contact your platform
vendor.

This happens with kernel 4.2.2.1 and a DVB-S-Card to be passed through to a vm under qemu 2.4.

... had I built a consumer-class PC for serving at home ... I think I had have no such problems.

Btw ... there are broken dependencies for the hp-scripting-tools- and hp-health-packages for debian jessie.

Please go on and give us a patched BIOS which is a bit more conform with standards (see advisory RedHat https://access.redhat.com/articles/1434873 )

[Jimmy Vance]

---

@ralfE wrote:

I get stuck with a Microserver Gen 8 with the same problem.

I applied the advisory (http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04781229&sp4ts.oid=5249566 ) to PCI Slot1 using the "conrep-stuff", still got the error message:

---

What is the outut of verify.dat using the command: # conrep -s -x conrep_rmrds.xml -f verify.dat

---

@ralfE wrote:

Btw ... there are broken dependencies for the hp-scripting-tools- and hp-health-packages for debian jessie.

---

What are the broken dependencies so I can report them

[ralfE]

<?xml version="1.0" encoding="UTF-8"?>
<!--generated by conrep version 4.4.0.0-->
<Conrep version="4.4.0.0" originating_platform="ProLiant MicroServer Gen8" originating_family="J06" originating_romdate="06/06/2014" originating_processor_manufacturer="Intel">
  <Section name="RMRDS_Slot1" helptext=".">Endpoints_Excluded</Section>
  <Section name="RMRDS_Slot2" helptext=".">Endpoints_Included</Section>
  <Section name="RMRDS_Slot3" helptext=".">Endpoints_Included</Section>
  <Section name="RMRDS_Slot4" helptext=".">Endpoints_Included</Section>
  <Section name="RMRDS_Slot5" helptext=".">Endpoints_Included</Section>
  <Section name="RMRDS_Slot6" helptext=".">Endpoints_Included</Section>
  <Section name="RMRDS_Slot7" helptext=".">Endpoints_Excluded</Section>
  <Section name="RMRDS_Slot8" helptext=".">Endpoints_Included</Section>
  <Section name="RMRDS_Slot9" helptext=".">Endpoints_Included</Section>
  <Section name="RMRDS_Slot10" helptext=".">Endpoints_Included</Section>
  <Section name="RMRDS_Slot11" helptext=".">Endpoints_Included</Section>
  <Section name="RMRDS_Slot12" helptext=".">Endpoints_Included</Section>
  <Section name="RMRDS_Slot13" helptext=".">Endpoints_Included</Section>
  <Section name="RMRDS_Slot14" helptext=".">Endpoints_Included</Section>
  <Section name="RMRDS_Slot15" helptext=".">Endpoints_Included</Section>
  <Section name="RMRDS_Slot16" helptext=".">Endpoints_Included</Section>
</Conrep>

And this for the dependencies:

The following packages have unmet dependencies:
 hp-health : Depends: libc6-i686 but it is not installable or
                      lib32gcc1 but it is not going to be installed
 hp-scripting-tools : Depends: lib32bz2-1.0 but it is not installable

Thanks for your reply so far ...

For the conrep output ...
I had tried "Slot7" as a "second" shot ... cause I wasn't shure if "Slot1" in BIOS is really Slot1. lspci reports the needed card to be on 0.07.00 ... so I tried "Slot7".

[Jimmy Vance]

The output does look correct. Please open a support case with HPE and reference the HPE customer advisory along with the Red Hat paper.

I will pass the dependency issue along to the team that works with the Debian versions of the tools

[ralfE]

Ok ... for everyone who suffers from this problem:

YOU ARE LOST ... HP will not accept this as existing problem ... WHY?

HP's answer: This configuration is unsupported. (may I add  "- as so often, when work is to be done")

Okay ... think about it and say it this way: Using an actual kernel on our HP-Server hardware is not supported and we will not consider to help you if you are running into problems. Nice standing ... and frustrating for the costumer - hopefully the next buying decision will be somewhat luckier.

In my opinion the only way to work around this effekt - else of returning the hardware to HP - will be to use an older kernelversion. Rumors are that the line of 3.16 will be a good startpoint. Have a shot at it ...

In HPs speaking this thread is ended with status "SOLVED" ........

[Jimmy Vance]

---

@ralfE wrote:

Ok ... for everyone who suffers from this problem:

YOU ARE LOST ... HP will not accept this as existing problem ... WHY?

HP's answer: This configuration is unsupported. (may I add  "- as so often, when work is to be done")

Okay ... think about it and say it this way: Using an actual kernel on our HP-Server hardware is not supported and we will not consider to help you if you are running into problems. Nice standing ... and frustrating for the costumer - hopefully the next buying decision will be somewhat luckier.

In my opinion the only way to work around this effekt - else of returning the hardware to HP - will be to use an older kernelversion. Rumors are that the line of 3.16 will be a good startpoint. Have a shot at it ...

In HPs speaking this thread is ended with status "SOLVED" ........

---

Did you open a case? If so please send me the case number here or in a private message

[ralfE]

This was the case number:

CASE:4764654455

Thank you for being interested ... but I am afraid you will not be allowed to help us, due to internal restraints at HP. You know that "This configuration is unsupported"-stuff ... for example if the hardware was upgraded with a more powerfull CPU and that else ... this goes into direction "Support for maker-szene" (doing things which are not thought be the manufacturer). But what is so far away, if someone is going to use an entrylevel server as homeserver for delevering Sat-TV over IP, serving some homepages and doing private mailservices ... and to encapsulate the services to a handfull virtual machines for easier handling? 

[Jimmy Vance]

Unfortuanely the case is mostly documented in German so I can't read it.  What I can translate and after looking at the CPU spec, the CPU in that model Microserver doesn't support VT-d

http://ark.intel.com/products/71074/Intel-Celeron-Processor-G1610T-2M-Cache-2_30-GHz

[ralfE]

You are right ... but it is now a:

Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz

which is fully capable of VTd ... The server was updated. In the case shall be a complete AHS-File ... which will show no issues on the hardware side. A warning maybe, due to the although upgraded memory using non-hp-branded ecc-memory from Kingston, but nothing to really worry about.

Today the server runs with VMWare 6.0.0 ... PCI-Passthrough works for the DVB-Sat-card. ... VMWare in 6.0.0. uses an older kernel than proxmox today. My design today is not very efficient ... proxmox is running as virtual machine ... a virtualization in the vitualization... nested -> not very desirable ... but the management of lxc-containers from proxmox is it worth. It was a pain getting VMWare to accept multiple VMs behind a virtual nic ... but it works for my needs. This does not mean, that I am pleased and the problem can be closed "solved":

My target is clearly to avoid VMWare and to run proxmox as virtualization native ....