Supermicro X11SCH-LN4F - PCI Passthrough Fehler / Problem

[tohe]

Hallo zusammen,

ich fange mit einem kleinen OffTopic an um die Historie zum aktuellen Problem zu schildern, wen es interessiert daher den Spoiler lesen

Spoiler

Vor einigen Jahren mit einem HP Microserver begonnen, diesen jedoch nach kurzer Zeit aufgrund Erweiterungsmöglichkeiten durch einen Proliant ML310 ersetzt inkl. P420 2GB FBWC Controller.
Dieser verrichtete einige Jahre lang zuverlässig seinen Dienst mit einigen VMs und einem TV-Server mit einer PCIe Karte von DigitalDevices, eine Cine S2, durchgereicht per PCI Passthrough, Hypervisor immer ESXi.
Letztes Jahr habe ich, nachdem ich lange Zeit schon unzufrieden mit der Performace war, mich dazu entschlossen diesen zu ersetzen. Die Wahl fiel aufgrund des Forums auf ein System mit Fujitsu D3644-B Mainboard und der HBA wurde durch einen Perc H310 im IT-Mode ersetzt. Verwöhnt durch die nun zufriedenstellende Leistung wurden die VMs mit mehr RAM bedacht und neue zogen mit ein, es machte wieder Spass sich mit neuem zu befassen
Dieser wurde mir nun wieder genommen nachdem ich auf ESXi v8 geupgradet habe, HBA offiziell nicht mehr unterstützt und um VMs gemäß MS compliance mit TPM etc. zu betreiben nun vSphere notwendig also war wieder RAM das Nadelöhr.
Kein Problem dachte ich und da das D3644-B gemäß C246 Spezifikation und Internetrecherche 128 GB RAM kann 4 x 32GB RAM besorgt.
VMWare gefrustet wollte ich nun aber aus Prinzip keine ESXi mehr einsetzen und zu proxmox wechseln, gesagt getan, jedoch habe ich dadurch auch gemerkt das das D3644-B wenn man es mit 4x32GB Modulen statt 4x16GB betreibt zu dauerhaften ECC Fehlern kommt (consolen Meldungen und memtest86 bestätigt) (mit unterschiedlichen Riegeln getestet - im Bios keinerlei Möglichkeiten am RAM was einzustellen) dazu auch habe ich es nicht hinbekommen per Intel vPro AMT Console nach dem grub von proxmox noch auf dieser per remote eine Monitorausgabe zu bekommen, bootet proxmox kein problem aber im Fehlerfall (steht halt nicht nebem Schreibtisch ...) ... also mich dazu entschlossen das das Board gewechselt wird hin zu 128GB Unterstützung und IPMI -> und hier beginnt der Weg mit dem Supermicro Board ...

Hardware:
Mainboard: Supermicro X11SCH-LN4F (Bios 1.9 - 09/19/2022)
CPU: Intel Xeon E-2146G
RAM: 128 GB M391A4G43BB1-CWE
Boot-Festplatte: Intel Optane P1600X
PCI: DigitalDevices Cine S2

Problem: PCI: DigitalDevices Cine S2 im PCI Passthroug funktioniert nicht / nicht zuverlässig

Ziel ist es unter Proxmox eine tvheadend Maschine zu betreiben. Im Legacy Betrieb habe ich es hinbekommen nach aktivieren von IOMMU die tvheadend VM zum laufen zu bekommen, aber nicht zuverlässig, im EFI Betrieb gar nicht.
Leider die Fehlermeldungen nicht rauskopiert, finde ich in meiner google orgie auch nicht mehr heraus. Kann ich aber nachrreichen.

Da ich Neuling bin was proxmox angeht habe ich also versucht tvheadend unter dem mir bekannten ESXi zum laufen zu bekommen, was auch augenscheinlich nach Installation von ESXi 8 und der tvheadend in einer VM unter Debian auch funktionierte. Dann aber Update von ESXi nachgeschoben und nach reboot wurde die PCI Karte nicht mehr unter den Hardware PCI-Geräten aufgeführt, VM startete nicht.
Nach einem Neustart war diese wieder da aber Passthroug deaktiviert -> musste wieder aktiviert werden.
Misstrauisch also wieder aktiviert und nach 5 reboots wieder das selbe Spiel, musste 2 x neustarten bis die Karte wieder auftausch, auch im Bios!!! Nach POPO (PowerOff-PowerON) wird die Karte gefühlt etwas eher erkannt ist aber auch keine Garantie. Ich habe also im Bios Einstellungen kontrolliert / geändert und protokolliert aber komme einem stabilen System nicht näher und bin mit meinem Latein am Ende.

Karte wird nur in dem unteren SLOT5 (x8) erkannt.
Nachfoldend ein paar Screenshots / Grafiken / Settings in der Hoffnung das diese hilfreich sind.

Wenn es funktioniert:

an den De-emphasis Control / Power Limit / Payload habe ich nichts verändert da ich mir dessen Settings nicht bewusst bin und werde.

Wenn PCI PERR/SERR aktiviert ist lässt sich dieser Fehler reproduzieren:

Danach wird die Karte weder im Bios noch ESXi gelistet:

nach 1-3 reboots wieder dann aber halt deaktiviert:

Hier wäre das Handbuch von dem Mainboard zu finden:
https://www.supermicro.com/manuals/motherboard/X11/MNL-2105.pdf

Wie gesagt ich bin mit meinem Latein am Ende und verzweifel so langsam. Ist das Board ungeeignet oder hat es eine Macke das spukt mir aktuell nur noch im Kopf herum, oder sehe ich den Wald von lauter Bäumen nicht

Was mich aber stört ist das im ESXi das Device unterhalb von dem x16 / SLOT6 angezeigt wird es aber definitiv im SLOT5 x8 Steckplatz steckt ...

Und dann noch hier die Settings der PCIe Config vom Bios: (hatte noch nie ein Bios gesehen wo man einzeln EFI / Legacy pro Device einstellen kann ...)

Ich danke Euch für Eure Ratschläge / Denkanstöße oder gar Lösung?

Schönen Abend!

 

[Potz]

Ich kann dir nicht weiterhelfen, aber vielleicht zwei deiner Fragen beantworten:

Was mich aber stört ist das im ESXi das Device unterhalb von dem x16 / SLOT6 angezeigt wird es aber definitiv im SLOT5 x8 Steckplatz steckt ...

Das ist korrekt so. Das Board verteilt die Lanes des PCIe x16 Ports der CPU auf zwei x8 Slots auf.

Und dann noch hier die Settings der PCIe Config vom Bios: (hatte noch nie ein Bios gesehen wo man einzeln EFI / Legacy pro Device einstellen kann ...)

Du kannst da einstellen welches OptionROM der eingesteckten Karten geladen werden soll. Das wirkt sich z.B. bei "besseren" NICs aus und entscheidet darüber ob man deren ROM im UEFI integriert konfigurieren kann, oder sie sich im Laufe des Bootprozesses kurz melden und du per Tastenkombination in deren Konfiguration wechseln kannst.

 

[besterino]

TV-Karten waren schon immer gerne mal etwas "eigen". Was passiert, wenn Du die Cine S2 in den obersten Slot (Slot 6?) setzt? Mal mit Legacy statt EFI auf dem Slot probiert?

Alternativ mal Hersteller- und Device-ID der Karte im ESXi raussuchen und in der Passthrough.map mal mit link, d3d0 bzw. bridge rumspielen.

Ansonsten: PCI-Device mal aus der VM löschen & Speichern. Passthrough der Karte deaktivieren. ESXi Reboot. Passthrough wieder aktivieren. ESXi Reboot. Wenn Karte in ESXi auftaucht, PCI-Device in der VM wieder hinzufügen & Speichern. ESXi Reboot. Immer noch alles da? VM starten... (Bei mir ist mit diversen Updates auch schonmal einiges durcheinander geraten und musste bisweilen alle passthrough-devices manuell erst aus den VMs entfernen und dann wieder hinzufügen, gerne auch mal passthrough deaktiveren / wieder aktivieren (glaub ESXi hat sich da bisweilen mit den Adressen verhaspelt). Im Zweifel also einmal alle Passthrough settings "zurück auf los" und sauber von vorne neu einrichten. Darum: never change a running system.

 

[Turboschnecke]

Ich hab das ganze vor Jahren mit ESXI und ner DVB-C Karten von DigitalDevices probiert und habe es dann am Ende Baremetal umgesetzt... DD konnte mir damals auch nicht weiterhelfen, weil die selber keine Virtualisierung/Passtrough unterstützen. Es kann funktionieren, muss es aber nicht^^
Baremetal lief es bei mir dann quasi Out-of-the-Box und komplett stabil. Unter ESXI hatte ich ständig Signalverluste usw und an der Verkabelung lag es nicht, die war danach nämlich immer noch die selbe^^

 

[tohe]

@Potz: Danke für deine Erklärungen, wieder was dazu gelernt.

TV-Karten waren schon immer gerne mal etwas "eigen". Was passiert, wenn Du die Cine S2 in den obersten Slot (Slot 6?) setzt? Mal mit Legacy statt EFI auf dem Slot probiert?

Alternativ mal Hersteller- und Device-ID der Karte im ESXi raussuchen und in der Passthrough.map mal mit link, d3d0 bzw. bridge rumspielen.

Ansonsten: PCI-Device mal aus der VM löschen & Speichern. Passthrough der Karte deaktivieren. ESXi Reboot. Passthrough wieder aktivieren. ESXi Reboot. Wenn Karte in ESXi auftaucht, PCI-Device in der VM wieder hinzufügen & Speichern. ESXi Reboot. Immer noch alles da? VM starten... (Bei mir ist mit diversen Updates auch schonmal einiges durcheinander geraten und musste bisweilen alle passthrough-devices manuell erst aus den VMs entfernen und dann wieder hinzufügen, gerne auch mal passthrough deaktiveren / wieder aktivieren (glaub ESXi hat sich da bisweilen mit den Adressen verhaspelt). Im Zweifel also einmal alle Passthrough settings "zurück auf los" und sauber von vorne neu einrichten. Darum: never change a running system.

- Habe ich schon öfters gelesen das TV-Karten Probleme machen, aber ich kann das nicht bestätigen diese Karte hat immer anstandslos in bisher 3 Servern ohne jegliche Sonderbehandlung funktioniert
- Stelle ich den PCI Slot von EFI auf Legacy wird das Problem gefühlt "etwas" weniger aber auch nicht zuverlässig ...
- An den map Settings in ESXi möchte ich aktuell nicht rumspielen da ich eigentlich zu proxmox wechseln möchte ... aber ggf. könnte das wirklich etwas helfen da in proxmox in den logs hierzu sowas zu finden ist:
proxmox kernel: vfio-pci 0000:01:00.0: can't change power state from D0 to D3hot (config space inaccessible)
proxmox kernel: vfio-pci 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible)
- Das System habe ich mehrmals komplett neu aufgesetzt und auch den tvheadend Server unter Debian, als keine VM verschoben etc. sprich keine alten Settings können pfuschen
- Aber zu dem "never change a runnig system" -> Wie sagte Watson? -> "Es gibt einen Weltmarkt für nur fünf Computer"

Ich hab das ganze vor Jahren mit ESXI und ner DVB-C Karten von DigitalDevices probiert und habe es dann am Ende Baremetal umgesetzt... DD konnte mir damals auch nicht weiterhelfen, weil die selber keine Virtualisierung/Passtrough unterstützen. Es kann funktionieren, muss es aber nicht^^
Baremetal lief es bei mir dann quasi Out-of-the-Box und komplett stabil. Unter ESXI hatte ich ständig Signalverluste usw und an der Verkabelung lag es nicht, die war danach nämlich immer noch die selbe^^

- Das würde ich gerne vermeiden weitere Kiste die rumsteht und energieeffizienter wird das auch nicht .. aber bin die Tage über das Zimaboard 216 gestolpert damit wäre es theoretisch Low-Budget mässig umsetzbar aber ... wird ne wilde Konstruktion + 2 Netzteile da die DD separat noch mit Strom versorgt werden will
Zimaboard -> oder gibt es da noch was in diese Richtung für einen simplen TV-Server, die 32GB eMMC sind schon dafür überdimensioniert -> Aufnahmen extern aufs NAS


FAZIT:
Ich werde es mit einem anderen Mainboard nochmal versuchen in der Hoffnung das es dann läuft wie bei den bisherigen 3 Servern ...


Bedanke mich und wünsche eine schöne bevorstehende Osterzeit

 

[Fusseltuch]

Kannst du evtl. mit USB-Tunern etwas reißen? Ich meine mich zu erinnern, dass die etwas unproblematischer sein sollen.

 

[tohe]

Kannst du evtl. mit USB-Tunern etwas reißen? Ich meine mich zu erinnern, dass die etwas unproblematischer sein sollen.

das würde sicherlich gehen aber ich würde gerne der "Nachhaltigkeit" wegen meine vorhandene Hardware nutzen ... und dann bräuchte ich 4 USB Tuner ... wobei vermutlich bei dem TV Angebot & Streaming etc. mittlerweile 2 Tuner reichen würden ... aber dann wäre eher meine Überlegung einen SAT-IP Server von Kathrein oder so zu holen ... bzw. ZimaBoard whatever - jedenfalls ich bin nicht bereit für den TV Mist viel Geld in die Hand zu nehmen

@On-Topic
habe ein anderes 1151v2 Board bestellt (Asrock Rack) entweder es geht damit dann und den 128GB RAM oder es bleibt beim Fujitsu D3644-B mit 64GB und dem Ressourcenproblem was RAM angeht aufgrund bei ESXi vSphere TPM Gängelung oder ich wechsel zu proxmox und schaue in wie fern sich 64GB mit ZFS und den VMs verhalten, bin zuversichtlich das Asrock Rack einfach funktionieren wird
-> trotzdem hätte ich gerne verstanden wieso das Supermicro nicht wollte

Überlegung / Frage
- das D3644-B _kann_ die 128GB RAM erkennen und nutzen -> ABER mit ECC Fehlern im Minutentakt, fühle mich damit nicht wohl und würde das ungern so betreiben
FRAGE: Seit ihr der selben Meinung oder kann man das auch ignorieren das ECC es ja im Prinzip regelt ... bitte in Hinsicht das ich ein stabiles System für die nächsten 3-5 Jahre haben möchte ...

so on ...

 

[AliManali]

ECC Fehler im Minutentakt würde ich jetzt nicht so stehen lassen. Ich hatte bei 128GB in drei Jahren noch keinen Einzigen.

 

[Potz]

Überlegung / Frage
- das D3644-B _kann_ die 128GB RAM erkennen und nutzen -> ABER mit ECC Fehlern im Minutentakt, fühle mich damit nicht wohl und würde das ungern so betreiben
FRAGE: Seit ihr der selben Meinung oder kann man das auch ignorieren das ECC es ja im Prinzip regelt ... bitte in Hinsicht das ich ein stabiles System für die nächsten 3-5 Jahre haben möchte ...

Ich sehe das wie du. Wenn da permanent Fehler gefunden werden, deutet das auf ein Problem hin, das ich nicht aussitzen wollen würde.

 

[underclocker2k4]

Ich würde da mal schauen bezüglich aktuellstem BIOS und dann auch am Ramtakt und an den Timings drehen.
Beim BIOS wird gerne mal sowas nachgeregelt. Bei mir hat das dazu geführt, dass nen SM Board mit AuslieferungsBIOS und Vollbestückung gar nicht booten wollte. Nur low clock hat geholfen, bzw. dann eben Update mit default.

Wenn BIOS-Update nicht hilft, dann mal mit extrem konservativen Einstellungen testen und schauen ob es weggeht.
In der Regel kommt so nen UDIMM-System mit soviel RAM-Last nicht ganz so gut zurecht. Daher haben RDIMM die Chips um den Bus zu entlasten. Dieser fehlt ja leider bei UDIMM.

 

[tohe]

Ich würde da mal schauen bezüglich aktuellstem BIOS und dann auch am Ramtakt und an den Timings drehen.
Beim BIOS wird gerne mal sowas nachgeregelt. Bei mir hat das dazu geführt, dass nen SM Board mit AuslieferungsBIOS und Vollbestückung gar nicht booten wollte. Nur low clock hat geholfen, bzw. dann eben Update mit default.

Wenn BIOS-Update nicht hilft, dann mal mit extrem konservativen Einstellungen testen und schauen ob es weggeht.
In der Regel kommt so nen UDIMM-System mit soviel RAM-Last nicht ganz so gut zurecht. Daher haben RDIMM die Chips um den Bus zu entlasten. Dieser fehlt ja leider bei UDIMM.

Das war auch mein erster Gedanke aber zum RAM Timings oder RAM allgemein hat das D3644-B keine Bios Einstellmöglichkeiten ...

 

[Potz]

Das Datenblatt zum D3644-B sagt:

Note: 128 GByte memory configuration (4x 32 GByte modules) not supported

Ich denke dann ist es wohl eine ziemliche Glücksache, ob es klappt oder nicht. Vielleicht haben sie beim PCB ein winziges Detail nicht ganz perfekt getroffen, so dass der maximal belastete Speicherkontroller nicht perfekt läuft. In dem Fall muss das ganze nicht einmal ausschließlich an den verwendeten DIMM-Exemplaren liegen, sondern die Qualität des Speichercontrollers in der CPU und des Mainboards hat auch einen Einfluss. Wäre dann eine üble Lotterie...