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

[ralfE]

Ahh ... thread moved to somewhere in "outer space" ... is this a sign that someone is working on the problem, or is it the confirmation of "closed as RESOLVED - not supported configuration" ... and so saying: "Sorry, we are not interested in your "exotic" problem and your usecase of our hardware?"

[Jimmy Vance]

---

@ralfE wrote:

Ahh ... thread moved to somewhere in "outer space" ...

I don't think the thread has moved anywhere

---

@ralfE wrote:

is this a sign that someone is working on the problem, or is it the confirmation of "closed as RESOLVED - not supported configuration" 

---

These forums are community based and assistance is provided by other users in the community, support cases are not really worked here.  Some of us that work for HPE try to assist here when we can.  I have not used passthrough mode so I can only go by what is in the Customer Advisory. 

You state it is working as expected with VMware, so it sounds like the information in the CA is correct. Why it isn't working with proxmox is anyone's guess.  Have you tried with some other supported flavor of Linux?

[ralfE]

Well, Jimmy ... I really appreciate to see a HP-Member who is interested in "this" sort of non-standard problems.
So here comes even more information ...

Some days are gone and I have tested the system in "production" ... watching and recording SAT-TV and presenting it to various clients like htpcs, tabletts, smartphones at home. And now I can say only the following: For my usecase - especially the virtualization with today VM-Ware 6.0.0 and the usage of a sat-reciever card with pci-passthrough - the GEN 8 Microserver is an absolute NO GO! Some posts earlier I was happy, that the dual-port DVB-SKY 952 was able to be passed to a virt. machine. For live-Watching everything was really fine ... but if the stream goes to storage it gets smashed - no recording was watchable, every few minutes I got pixeled videos for about 10 to 20 seconds with cuts in audio too. I checked the recording local to eleminate networking problems ... it was as scrambled as through network delivery. Something very bad must be happened with the stream when going directly from PCIe to Network II (storage is a ISCSI-Disk).
I cannot explain why PCIe to Network I (live watching) worked flawless. Are Network I and II bound to different bridges (Noth, South)? ... if so I will reconfigure the complete system and bind the ISCSI to Network I and check this.
After this I changed the SAT-reciever to my old single reciever-card (tt s2-4100) which was serving me for years in my old system with VM-Ware 5.5. This card was not able to be passed through to the virtual vdr. The logs of VM-Ware complained about not being able to reset the card on the pci-bus ... and there the by RedHat described problem is again visible.
What works today is a USB-sat-reciever passed through to the vdr ... but this a compromise with drawbacks on the WAF (the feared woman-acceptance-factor) :)
For me this is only a hobby and I am willing to spend hours of testing and frustration, but this hardware is friendly said the most thrilling one I ever had. Today I still believe that it is possible to reach my target ... but there where thoughts containing "ebay" already. Well choosen consumer-hardware in a self-build-system cannot be worse.

Btw ... the "rest" - the simple stuff; serving e-mail, hosting webpages, runing virt. desktops - works without complications and is (until today) rock solid ...
And a note back to the linux-flavour ... every distribution which uses stock-kernel 4.x will have the problems with IOMMU due to a not standard conform usage of the PCIe-Bus. The "Device is ineligible for IOMMU domain attach due to platform RMRR requirement"-Message is in my understanding a very close to hardware and very deep in kernel-check to stop a isolated PCI-card from accidently writing to memory areas outside of her isolation - which will be a serious security breach and a possible worst-case for the host if it goes into an active diskIO or something that way.

[Jimmy Vance]

To bad it hasn't worked out for your usage model.  Have you checked over at the Home Server Show forums http://homeservershow.com/forums/index.php?/forum/96-hp-servers/ ? The users there do a lot of experimenting with the hardware.

[pharidos]

I am not able to disable RMRR for slots greater than 16

pharidos@uks9:~/pt$ cat exclude.dat
<Conrep>
<Section name="RMRDS_Slot4" helptext=".">Endpoints_Excluded</Section>
<Section name="RMRDS_Slot5" helptext=".">Endpoints_Excluded</Section>
<Section name="RMRDS_Slot88" helptext=".">Endpoints_Excluded</Section>
</Conrep>

pharidos@uks9:~/pt$ sudo conrep -l -x conrep_rmrds.xml -f exclude.dat 
conrep 4.6.0.0 - HPE Scripting Toolkit Configuration Replication Program
(c) Copyright 2013,2016 Hewlett Packard Enterprise Development LP

System Type: ProLiant DL380 Gen9
ROM Date : 03/05/2015
ROM Family : P89
Processor Manufacturer : Intel(R) Corporation

XML System Configuration: conrep_rmrds.xml
Hardware Configuration: exclude.dat
Global Restriction: [3.40 ] OK

Loading configuration data from exclude.dat

ERROR: Invalid dat file entry RMRDS_Slot88

Conrep return code: 2

pharidos@uks9:~/pt$ lspci -s 88:
88:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01)
88:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01)
pharidos@uks9:~/pt$ 

pharidos@uks9:~/pt$ dmesg | grep -i "Setting identity map for device.*88"
[    0.908246] DMAR: Setting identity map for device 0000:88:00.0 [0x791dc000 - 0x791ebfff]
[    0.908349] DMAR: Setting identity map for device 0000:88:00.0 [0x791ec000 - 0x791effff]
[    0.908363] DMAR: Setting identity map for device 0000:88:00.1 [0x791ec000 - 0x791effff]

[drymis]

I have the same hp-health install problems, but I am running Ubuntu Server 14.04 x64 directly on a Proliant DL360 (noVM). 

$ aptitude install hp-health
The following NEW packages will be installed:
 hp-health lib32gcc1{ab} libc6-i386{ab}
0 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,711 kB of archives. After unpacking 12.2 MB will be used.
The following packages have unmet dependencies:
 lib32gcc1 : Depends: gcc-4.9-base (= 4.9-20140406-0ubuntu1) but 4.9.1-0ubuntu1 is installed.
 libc6-i386 : Depends: libc6 (= 2.19-0ubuntu6) but 2.19-0ubuntu6.6 is installed.

$ apt-get install hp-tools
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

$ apt-cache policy hp-health
hp-health:
  Installed: (none)
  Candidate: 10.40-1815.49
  Version table:
     10.40-1815.49 0
        500 http://downloads.linux.hpe.com/SDR/downloads/MCP/ubuntu/ trusty/current/non-free amd64 Packages

So your problem is not unique. Were you able to get hp-health installed on your system?

[lchen]

suffered from the same issue.  I wouldn't buy this product if I had checked out this thread and knew how HP responeded to the support case. disppointed