Mein 10 Zoll Server

[jj1987]

13 minutes ago, MPC561 said:

@jj1987

Sicher das das nach 10 Minuten wenn er die Grafik deaktiviert auch noch so ist?

 

Wobei ich das mit 6.9. bei meinem ASROCK B460m Board auch schonmal beobachtet hatte und es war irgendwas mit der iGPU, soweit hatte ich damals nachgeforscht. Irgendwie ging nach sleep die iGPU nicht mehr in den Idle.

 

Gruss,

Joerg

Ja ist auch nach Stunden noch so.

Laut Powertop ist die iGPU in beiden fällen in PC6 

[mgutt]

Ok, ich konnte das problematische Kommando isolieren:

 

for i in /sys/class/net/eth?; do dev=$(basename $i); [[ $(echo $(ethtool --show-eee $dev 2> /dev/null) | grep -c "Supported EEE link modes: 1") -eq 1 ]] && ethtool --set-eee $dev eee on; done

 

Danach rastet "/usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_3" aus und das Terminal ist komplett tot, sobald ich das gerade offene Terminal schließe:

 

 

Witzigerweise wird das Kommando beim Booten über die Go-Datei ja auch gestartet.

 

Ich starte jetzt mal neu und versuche genau zu isolieren, welcher Teil des Kommandos das Problem verursacht.

 

EDIT1: Interessant. Jetzt startet der Server nicht mehr bzw crasht nach ca 1 Minute (sehe ich am Monitor, dann blinkt der Cursor nicht mehr bei der Eingabe des Usernames).

 

EDIT2: So, die problematische Zeile aus der Go-Datei habe ich auskommentiert. Nun fährt der Server wieder hoch. Insgesamt hatte ich 3 Abstürze. Keinerlei Kernel-Fehler in den Logs zu finden. Auch nicht live auf dem Monitor. Allerdings habe ich massig diesen Fehler, was darauf hindeutet, dass der uralte Bug mit dem "Fenster ist noch offen und Unraid schmiert dann ab", nach wie vor präsent zu sein scheint (sollte ja eigentlich in 6.10 gelöst sein):

Jun 26 12:24:31 Tower nginx: 2022/06/26 12:24:31 [error] 4268#4268: *26 limiting requests, excess: 20.202 by zone "authlimit", client: 192.168.178.21, server: , request: "GET /login HTTP/1.1", host: "tower", referrer: "http://tower/Dashboard"

 

EDIT3: Ok, damit hätte ich wohl den Übeltäter ausgemacht. ethtool lässt den SSH Dienst crashen (man kann ab dann auch kein Array mehr stoppen und auch nicht herunterfahren, die WebGUI geht aber noch):

ethtool eth0

 

Eine erneute Verbindung lässt sich dann auch nicht mehr aufbauen:

 

Mag das jemand testen? Bitte aber vorher das Array stoppen, damit beim Reboot nicht direkt wieder ein Parity Check gemacht wird 😉

 

Ich mache jetzt noch mal einen Test, wo ich parallel "top" laufen lasse, damit ich sehe, was da eigentlich ausrastet, weil ich diesmal von extern eine SSH Verbindung aufgebaut hatte und ich kann mir eigentlich nur schwer vorstellen, dass dadurch ein PHP-Skript ausrasten kann.

 

EDIT4: Interessant. Jetzt hat der Server einfach seine Zeit vergessen 🤔

 

EDIT5: Unraid hat einfach drei Dateien auf dem USB-Stick überschrieben

 

In meinem Backup hatte die Datei noch den Zeitstempe vom 23.05.:

 

Die NTP-Server sind auch alle weg. Standardmäßig trägt Unraid da "time1.google.com" usw ein:

 

SSH usw war jetzt auch deaktiviert. Wie kann das bitte sein, dass Unraid einfach die Dateien überschreibt?!

 

EDIT6: Ok, es passiert nur bei ethtool eth0 und nicht bei ethtool eth1:

 

Ich denke das Problem ist irgendwo bei den Netzwerk-Einstellungen zu finden. Und zwar habe ich bewusst keine Einstellungen verändert. Alles Standard. Das Netzwerkkabel steckt in eth1 (MAC endet auf "DA"). In eth0 steckt kein Kabel.

 

 

EDIT7: Ein Kabel in eth0 gesteckt. ethtool eth0 aufgerufen und Crash... Das hätte ich jetzt nicht erwartet. Mal sehen ob das auch nach einem Reboot so ist.

 

EDIT8: Ok, nach einem Neustart und mit eth0 verbunden, geht nun auch ethtool eth0:

 

Ich ändere jetzt mal die Netzwerk-Config so ab, dass eth0 das zweite Device wird und umgekehrt.

 

EDIT9: Jetzt ist es genau umgekehrt. Nun schmiert der Server mit ethtool eth1 ab, wenn da kein Kabel drin steckt.

[mgutt]

Ok, also ich bin mir ziemlich sicher, wann ich den quasi Server-Crash auslösen kann:

- Server hat zwei LAN-Buchsen

- nur in einer steckt ein Kabel

- Netzwerk-Einstellungen stehen auf active-backup (Unraid Standard-Einstellung = keine network.cfg vorhanden)

- "ethtool eth0" oder "ethtool eth1" lassen den Server abschmieren, je nachdem wo kein Kabel drin steckt

- jetzt teste ich mal ob das auch passiert, wenn die Go File keine Stromsparkommandos enthält EDIT: Nein, kein Absturz. Also ist es eine Kombination aus Stromsparkommando und kein Kabel steckt drin. Jetzt mal herausfinden welches Kommando die Ursache ist.

 

EDIT2:

Also das passiert nur, wenn man bei allen PCIe Geräten den Stromsparmodus auf Auto stellt:

echo auto | tee /sys/bus/pci/devices/????:??:??.?/power/control

 

Ich vermute mal, dass wenn dann kein Kabel in der Buchse steckt, dass Linux die Buchse dann quasi abschaltet und wenn man dann ethtool ausführt, dass der Server dann crasht. Ich versuche nun das genaue Device zu ermitteln, welches den Bug auslöst.

 

@ich777

Schon mal was ähnliches gehört?

 

[ich777]

52 minutes ago, mgutt said:

@ich777

Schon mal was ähnliches gehört?

Um was gehts hier genau? Crasht dein server?

[mgutt]

32 minutes ago, ich777 said:

Um was gehts hier genau? Crasht dein server?

Es ist ein halber Crash. Der Server läuft quasi noch, aber man kann nicht mehr neustarten, herunterfahren und diverse andere Dinge gehen auch nicht mehr. Das Terminal stirbt zB.

 

Voraussetzung dafür ist, dass ich bei dieser nicht genutzten Ethernet-Buchse (eth0):

07:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-LM [8086:15f2] (rev 03)

 

den Stromsparmodus auf "auto" stelle:

echo auto | tee /sys/bus/pci/devices/0000:07:00.0/power/control

 

Und dann danach das Kommando ausführe:

ethtool eth0

 

Alternativ zu "ethtool" kann ich auch einfach nur in den Netzwerk-Einstellung von Unraid was ändern. Auch das führt dann zum Crash.

 

PS der Standardwert bei diesem Device ist "on":

 

Ich teste das jetzt auch mal mit Ubuntu.

 

EDIT1: In Ubuntu hat man das Problem nicht. In dem Fall gibt ethtool einfach zurück, dass das Device nicht existiert, wenn man auf "auto" gestellt hat. Man kann es sogar problemlos wieder mit "on" aktivieren:

[email protected]:~$ ethtool enp7s0
Settings for enp7s0:
...
    Speed: Unknown!
    Duplex: Unknown! (255)

[email protected]:/home/ubuntu# echo "auto" > /sys/bus/pci/devices/0000:07:00.0/power/control

[email protected]:/home/ubuntu# ethtool enp7s0
Settings for enp7s0:
Cannot get device settings: No such device

[email protected]:/home/ubuntu# ethtool -i enp7s0
Cannot get driver information: No such device

[email protected]:/home/ubuntu# echo "on" > /sys/bus/pci/devices/0000:07:00.0/power/control

[email protected]:/home/ubuntu# ethtool -i enp7s0
driver: igc
version: 0.0.1-k
firmware-version:
expansion-rom-version:
bus-info: 0000:07:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

 

[MPC561]

Wieso deaktivierst Du nicht einfach im Bios einen LAN Port? Hab ich so und deswegen wahrscheinlich keine Probleme.

 

Wobei ja ich versteh schon, Du willst herausfinden woher es kommt.

 

Gruss,

Joerg

[mgutt]

19 minutes ago, MPC561 said:

Wobei ja ich versteh schon, Du willst herausfinden woher es kommt.

Genau, das ist ja mein Testserver und das Feedback dient ja mehr für Limetech und damit der Verbesserung von Unraid als für mich selbst. Daher habe ich auch gleich mal einen Bug-Report aufgemacht.

 

Es nutzen ja massig Leute "powertop --auto-tune" oder meine Kommando-Liste in der Go-Datei und die wissen dann einfach gar nicht warum ihr Server crasht. Jetzt weiß ich zumindest warum mir mein produktiver Server so oft abgeschmiert ist, als ich die 10G Karte verbaut hatte und die Reihenfolge der Karten usw über die GUI ändern wollte. 🤪

 

[mgutt]

On 6/26/2022 at 8:00 AM, mgutt said:

Mein Testserver (W480M) verbraucht mit Stromsparkommandos wie gesagt 13W. Irgendwann steigt das aber einfach auf 19W.

@MPC561

Das Problem ist jetzt übrigens weg, seitdem ich den 2. LAN Port im BIOS deaktiviert habe. Liegt also an dem Bug. Vermutlich hat Unraid später noch versucht auf den LAN-Port zuzugreifen und da war der Server dann schon halb gecrasht und der Verbrauch ging deswegen hoch. Jetzt durchgehend 13W 😋

[mgutt]

Ich versuche gerade mal den RAM zu übertakten, damit ich ECC Fehler provozieren kann. Ich habe im BIOS die Geschwindigkeit von 3200 auf 3333 erhöhen können, aber was scheinbar nicht angewendet wird, sind die von mir eingestellten 1.3V?!

 

# dmidecode --type 17
...

        Configured Memory Speed: 3333 MT/s
        Minimum Voltage: 1.2 V
        Maximum Voltage: 1.2 V
        Configured Voltage: 1.2 V

 

Ich habe dann eine große RAM-Disk erstellt und eine Datei mit zufälligem Inhalt reingeschrieben und erstelle davon 3x einen MD5 Hash (der immer gleich bleiben muss):

mkdir /mnt/ram
mount -t tmpfs -o size=8G tmpfs /mnt/ram
dd if=/dev/urandom of=/mnt/ram/test.bin bs=128k iflag=count_bytes count=8G
md5sum /mnt/ram/test.bin
md5sum /mnt/ram/test.bin
md5sum /mnt/ram/test.bin
umount /mnt/ram

 

Bisher konnte ich keine ECC Fehler provozieren. Ich versuche jetzt mal 3466 Mhz. Was könnte ich sonst noch für "instabile" Einstellungen für den RAM auswählen?

 

EDIT: Ok mit 3466 bootet er auch noch. Und die MD5 Prüfsummen sind auch alle sauber:

878062ecd9ca99e7838886e223c8bb80  /mnt/ram/test.bin
878062ecd9ca99e7838886e223c8bb80  /mnt/ram/test.bin
878062ecd9ca99e7838886e223c8bb80  /mnt/ram/test.bin

 

EDIT: Bei 3600 bootete er erst wieder als ich ein RAM-Modul ausgebaut habe. Aber auch damit kein Fehler:

179cfcb349cdde61a12241d25c31c045  /mnt/ram/test.bin
179cfcb349cdde61a12241d25c31c045  /mnt/ram/test.bin
179cfcb349cdde61a12241d25c31c045  /mnt/ram/test.bin

 

Und nun? Ich denke nicht, dass der bei 3733 noch hochfährt 🤔

[DataCollector]

2 hours ago, mgutt said:

Ich habe im BIOS die Geschwindigkeit von 3200 auf 3333 erhöhen können, aber was scheinbar nicht angewendet wird, sind die von mir eingestellten 1.3V?!

Normalerweise erhöht man die Spannung um Stabilität zu erreichen. Du willst doch das Gegenteil haben. Also versuch doch mal zu undervolten.

 

2 hours ago, mgutt said:

Ich habe dann eine große RAM-Disk erstellt und eine Datei mit zufälligem Inhalt reingeschrieben und erstelle davon 3x einen MD5 Hash (der immer gleich bleiben muss):

mkdir /mnt/ram
mount -t tmpfs -o size=8G tmpfs /mnt/ram
dd if=/dev/urandom of=/mnt/ram/test.bin bs=128k iflag=count_bytes count=8G
md5sum /mnt/ram/test.bin
md5sum /mnt/ram/test.bin
md5sum /mnt/ram/test.bin
umount /mnt/ram

Selbst wenn ein ECC Fehler auftritt, würde der ja erstmal ausgebügelt. Erst wenn der Fehler zu massiv ist (mehr als 1 Bit falsch kippt) wird es auffallen.

 

 

2 hours ago, mgutt said:

Bisher konnte ich keine ECC Fehler provozieren.

Ich mutmaße: Dir wurde bisher keiner angezeigt.

Ob einer aufgetreten und stillschweigend korrigiert wurde, wirst Du vermutlich nie mitbekommen.

 

2 hours ago, mgutt said:

Ich versuche jetzt mal 3466 Mhz. Was könnte ich sonst noch für "instabile" Einstellungen für den RAM auswählen?

massiv undervolten.

[mgutt]

21 hours ago, DataCollector said:

Also versuch doch mal zu undervolten.

Irgendwie geht das nicht. Ich stelle zwar eine geringere Voltzahl ein, aber der scheint die nicht zu übernehmen.

 

21 hours ago, DataCollector said:

Ich mutmaße: Dir wurde bisher keiner angezeigt.

Wenn er sie korrigieren kann, wäre mir das egal, aber nicht, wenn das auch bei nicht korrigierbaren Fehlern passiert. Da ich aber mit md5sum keine Abweichungen habe, habe ich denke ich auch keine nicht korrigierbaren Fehler gehabt. Also RAM ist noch nicht "kaputt" genug ^^

 

Laut hier soll man /sys/devices/system/edac/mc/mc0/ue_count finden können. Bei mir ist da aber leider nicht mal "mc0":

https://www.kernel.org/doc/html/latest/admin-guide/ras.html#dimmx-or-rankx-directories

https://serverfault.com/questions/643542/how-do-i-get-notified-of-ecc-errors-in-linux

https://serverfault.com/a/868378/44086

ls /sys/devices/system/edac/mc
power/  [email protected]  uevent

 

Was man noch einstellen könnte, wäre Kernel Panic bei unkorrigierbaren Fehlern:

https://www.kernel.org/doc/html/v4.10/admin-guide/ras.html#module-parameters

 

Bei mir steht edac_mc_panic_on_ue zB auf 0:

# tail -n +1 /sys/module/edac_core/parameters/*
==> /sys/module/edac_core/parameters/check_pci_errors <==
0

==> /sys/module/edac_core/parameters/edac_mc_log_ce <==
1

==> /sys/module/edac_core/parameters/edac_mc_log_ue <==
1

==> /sys/module/edac_core/parameters/edac_mc_panic_on_ue <==
0

==> /sys/module/edac_core/parameters/edac_mc_poll_msec <==
1000

==> /sys/module/edac_core/parameters/edac_pci_panic_on_pe <==
0

 

Dann schmiert der Fehler bei nur einem Fehler ab. Wobei ich ja scheinbar nicht mal einen Fehler habe. Zumindest wird keiner geloggt, obwohl edac_mc_log_ce und edac_mc_log_ue beide aktiv sind (also eigentlich sollte er auch Korrekturen melden, wenn ich das richtig verstehe).

 

Mich irritiert aber diese Anmerkung:

Quote

 

If the kernel has MCE configured, then EDAC will never notice the UE

 

 

EDIT: OK, das ist komisch. Mein produktiver Server mit Unraid 6.9 hat alle Unterverzeichnisse:

# ls /sys/devices/system/edac/mc/mc0
ce_count         csrow0/  max_location  power/  rank1/  rank3/          seconds_since_reset  ue_count         uevent
ce_noinfo_count  csrow1/  mc_name       rank0/  rank2/  reset_counters  size_mb              ue_noinfo_count

 

Aktuell stört mich auch, dass der Verbrauch vom Testserver völlig inkonsistent ist. Ich meine ich nutze den ja überhaupt nicht. Trotzdem zeigt der keine gerade Linie, wie ich es erwarten würde. Ich glaube ich teste noch mal Unraid 6.9, ob das da auch so ist.

 

[mgutt]

Na toll. Unraid 6.9 schlägt Unraid 6.10 sowohl bei den C-States als auch beim Verbrauch

 

 

Wie man sieht bleiben auch die Schwankungen aus:

[mgutt]

Wegen dem C246N hatte ich Gigabyte mal gefragt ob das BIOS evtl einen Bug hat, weil beim Auslesen der ECC Bandbreite ein falscher Wert angezeigt wird (korrekt wären 72 statt 128 bits):

# dmidecode -t 17
...
Total Width: 128 bits
Data Width: 64 bits

 

Die Antwort ist ernüchternd:

Quote

Da wir das OS Linux nicht Supporten und im Windows es keine Fehler bezüglich dem ECC gibt, müssen wir von einem Auslesefehler von Linux ausgehen.

 

Ich müsste also erst mal mit Windows diesen Wert auslesen. Dafür habe ich keine Möglichkeit, weil das ja mein produktives System ist

[mgutt]

Nach gefühlt 100 Jahren endlich einen gebrauchten Xeon für mein C246M gefunden. Ein E-2186G für knapp 200 €.

[mgutt]

Gerade mal mein Test-Setup W480M+W-1290E+NVMe+64GB-RAM+LAN+USB-Stick gemessen:

 

Ubuntu Desktop 22.04.1 LTS

 

Unraid 6.11

 

Damit kommt Unraid 6.11 immer noch nicht auf das Niveau von Ubuntu, aber endlich wieder auf das Niveau von Unraid 6.8. Sehr erfreulich!

[mgutt]

Das C246M-WU4+E-2186G+NVMe+64GB-RAM+LAN+USB-Stick ist allerdings mal wieder unschlagbar:

 

Mich irritieren nur wie gehabt die Spitzen. Seit Unraid 6.10 kommt das immer wieder mal vor.

[unifiedmamba]

Dein Verbrauch ist ja mal absoluter Hammer. 

 

Ich bin schon froh meinen Verbrauch auf ca. 40-50 Watt im idle gesenkt zu haben.

Ich vermute aber dass ein allein mein UPS ca. 10 Watt verbrät, dafür crasht mir im Fall der Fälle halt nicht das NAS.

 

Mein neuer Ryzen 5600G verbraucht aber immerhin im idle weniger als der lahme Athlon 200GE. 

[mgutt]

2 hours ago, unifiedmamba said:

Ich bin schon froh meinen Verbrauch auf ca. 40-50 Watt im idle gesenkt zu haben.

Ist jetzt gemein, aber heute als ich angefangen habe, hab ich mich voll aufgeregt, weil ich nicht unter 22W kam, bis ich gemerkt habe, dass ich 8 SSDs am Netzteil hatte. Ich hatte nur SATA abgeklemmt und kam nicht zum verrecken dahinter warum der bei C9 immer noch so viel verbraucht hat 😅

[warp760]

13 hours ago, mgutt said:

Mich irritieren nur wie gehabt die Spitzen.

Ich hab die leider auch...

 

[mgutt]

Wieder was über IPv6 gelernt: Will man seine DDNS Domains lokal über IPv6 erreichen, muss man in der Fritz!Box die Domain im DNS-Rebind-Schutz ausnehmen. Ich dachte das greift nur bei lokalen IPs, aber tatsächlich blockt die Fritz!Box dann grundsätzlich die gesamte IPv6 Auflösung, auch wenn es eigentlich eine öffentliche IPv6 ist.

 

D.h das geht:

dig tower.example.com A
123.456.78.9

 

das aber nicht:

dig tower.example.com AAAA

 

Erst wenn man "example.com" auf der DNS-Rebind-Schutz Liste ausnimmt, kommt auch eine öffentliche IPv6 zurück.

dig tower.example.com AAAA
1000:2000:3000:4000:5000:6000:7000:8000

 

[mgutt]

Ich habe jetzt auch Adguard Home installiert und wie man sieht meide ich br0 grundsätzlich, weshalb ich auch kein Host Access aktivieren muss und keine Probleme bei den Verbindungen zwischen den Containern habe

 

 

Ehrlich gesagt wundert es mich, dass Adguard im Bridge Modus so problemlos funktioniert. Ich hatte vermutet, dass Adguard nur eine eingehende IP sieht (die von Unraid), aber in Adguard sieht alles fein aus 😎

 

Allerdings musste ich adguards Standardport 3000 ändern, weil zu meiner Überraschung der NPM ebenfalls auf 3000 lauscht. Da muss ich mal den Entwickler fragen was das soll.

[mgutt]

Ich habe noch eine RTX3050 rumfliegen und nutze die jetzt mal für einen Verbrauchstest beim C246M. Ohne GPU komme ich bekanntlich auf unter 8W.

 

Bei einem ersten Test wollte ich wissen, ob man die GPU nachträglich erst mit dem 8 Pin mit Strom versorgen kann und dann mit folgendem Befehl "zum Leben" erwecken kann, was aber leider nicht funktioniert hat:

 

echo 1 > /sys/bus/pci/rescan

 

Die Idee wäre dann gewesen die dGPU nur bei Bedarf mit Strom zu versorgen und solange zB eine Gaming VM aus ist, überhaupt nicht mit Strom zu versorgen.

 

Dann habe ich mit der dGPU neu gestartet. Das BIOS wählte sie direkt als primäre GPU aus. Das habe ich dann auf die iGPU geändert. Nach dem Booten und ohne Nvidia Treiber sah der Verbrauch dann so aus:

 

 

Also knapp 25W. Ein HDMI Kabel ist verbunden, aber das Bild bleibt wie erwartet schwarz.

 

Angezeigt wird mir die Karte in IOMMU Gruppe 1 

 

 

Mehr als C3 ist nicht drin:

 

 

 

EDIT1:

Ich habe dann den 8-Pin im laufenden Betrieb gezogen. Wieder um zu sehen was passiert. Der Verbrauch sank dadurch auf 9,6W. In der IOMMU Liste ist die Karte nach wie vor zu sehen. Allerdings gibt es diverse Fehler im syslog:

 

 

EDIT2:

Der 8-Pin wurde wieder verbunden. Der Verbrauch des Systems steigt auf gerade mal 10,5W an. Neue Logeinträge gibt es nicht. Ob die Karte funktioniert? Ich habe mal zum Test einen rescan ausgelöst. Die Karte bleibt in der Geräteliste stehen (ich hätte erwartet, dass die jetzt rausfliegt).

 

Update folgt...

[alturismo]

15 hours ago, mgutt said:

Mehr als C3 ist nicht drin:

 

bestätigt ja (leider) meine Theorie, sowie was verbaut ist ... geht da einfach nichts mehr.

 

15 hours ago, mgutt said:

Ich habe dann den 8-Pin im laufenden Betrieb gezogen. Wieder um zu sehen was passiert. Der Verbrauch sank dadurch auf 9,6W. In der IOMMU Liste ist die Karte nach wie vor zu sehen. Allerdings gibt es diverse Fehler im syslog:

 

interessanter (harter) Ansatz, wäre ja irre wenn die dann zurück käme, dann müssten wir uns etwas "schaltbares" bauen um die dGPU's im idle richtig "schlafen" zu legen

 

### Nachtrag

 

da ich ja auch versucht hatte mit Gewalt das Thema C States anzugehen vielleicht etwas für Dich um die devices raus / rein zu holen vor/nach Strom aus/an

 

das reine software remove/rescan bringt leider nichts, weder beim Verbrauch (im Gegenteil, die Karten verlieren Ihren p state und brauchen mehr) noch bei den C States der CPU, bleibt trotzdem alles bei C3 stehen hier.

 

der erste Befehl holt die Karte aus dem System, vielleicht hilft das "vor" Power aus ...

echo 1 > /sys/devices/pci0000:00/0000:00:01.0/remove

echo 1 > /sys/bus/pci/rescan

damit geht die Karte aus dem System und kommt wieder retour (ohne dazwischen jetzt den Steck zu ziehen )

[mgutt]

Danke, das probiere ich in jedem Fall auch aus!

 

EDIT1:

Die Karte habe ich NICHT an VFIO gebunden und bei einer neuen Ubuntu22 VM durchgeschliffen:

 

Die VM startet problemlos und ich kann Ubuntu auf dem angeschlossenen Monitor sehen. Kurz gewartet und der Verbrauch pendelte sich bei 26,8W (C3) ein. Ubuntu ist aber noch nicht installiert.

 

Bei der Installation habe ich dann Drittanbieter für Grafik ausgewählt, da ich annehme, dass dadurch erst die Nvidia Treiber installiert werden:

 

EDIT2:

Ubuntu bootet nicht wegen diesem Bug:

https://askubuntu.com/questions/1417618/mtd-device-must-be-supplied-device-name-is-empty

 

Ich lade dann mal Ubuntu 20 🤪

 

EDIT3:

Ubuntu20 ist installiert. Allerdings sehe ich auf der dGPU nur die Meldung "BdsDxe loading/starting Boot004 ubuntu from HD"?! Mag der das nicht, wenn man VNC + dGPU hat 🤨Die dGPU ist auch nicht nach längerer Zeit in den Standby gegangen. Also Bild ist durchgehend zu sehen.

 

EDIT4:

Noch mal neu installiert und versehentlich die Sprache bei VNC auf Englisch gestellt. Dann nach der Installation auf Deutsch. Jetzt kann ich mich nicht mehr anmelden, weil das Passwort Buchstaben enthält, die nun völlig anders sind 😅

 

EDIT5:

Noch mal Ubuntu22 installiert und diesmal hat es geklappt. Ich vermute, weil ich nach "Remove the boot medium" die VM erzwungen gestoppt habe, hatte ich irgendwas gekillt. Jedenfalls habe ich nun die ISO drin gelassen und konnte ganz normal rebooten. Diesmal habe ich minimale Installation und ohne Drittanbieter gewählt. Stattdessen installiere ich den Nvidia Treiber über "Aktualisierungen":

 

EDIT6:

Den "open Kernel" Treiber hätte ich nicht nehmen dürfen:

https://forums.developer.nvidia.com/t/nvidia-smi-no-devices-were-found-on-ubuntu-22-04-lts-dual-boot-with-windows-10-geforce-rtx-3060-intel-corei7/232516

Daher habe ich nun den ohne "open" genommen:

 

EDIT7:

Nach Reboot der VM geht der Monitor nun aus. Aber in den Ubuntu Einstellungen kann ich nach wie vor keinen zweiten Monitor sehen 🤨

 

EDIT8:

Über nvidia-smi kann ich aber nun im Gegensatz zu vorher die Karten-Informationen sehen:

 

In den Nvidia Settings zeigt er auch bei "Screens" eine 1:

 

Keine Ahnung wie das hier aussehen muss?!

 

EDIT9:

Da ich ja über die virtuelle GPU verbunden bin, frage ich mich gerade, ob man auf diesem Weg überhaupt den Nvidia Monitor aktivieren kann. Ich habe ja die Session an die VNC GPU gebunden... hmmm 🤔

 

Verbrauchen tut der Server jetzt übrigens 17W. Also der Treiber scheint in jedem Fall aktiv zu sein. Wobei 9W nur für die Karte ohne Ausgabe am Monitor schon hart ist.

 

EDIT10:

Also das ist echt unnötig kompliziert. Ich musste jetzt erst mal lernen, dass VNC nicht gleich VNC ist. Also was ich zuerst dachte: Installiere irgendeinen VNC Server und verbinde dich einfach über VNC auf die Ubuntu VM und du siehst das was du auch über Unraids virtuelle VNC GPU siehst. Denkste. Nur bestimmte VNC Server zeigen auch das an, was der User sieht. Die meisten machen eine komplett neue Session auf und man hat quasi einen leeren Desktop und der Bildschirm vom User ist "aus". Nur x11vnc oder RealVNC scheinen es so zu machen, wie man es auch von Teamviewer usw her kennt. x11vnc habe ich nicht zum Laufen gebracht. Der bemängelte ständig, dass display :0 nicht existieren würde. xrandr fand dann plötzlich auch gar keine Displays mehr... also RealVNC installiert und läuft wunderbar. Aber auch hier nur die Verbindung zur virtuellen VNC GPU. Nvidia bliebt tot. Also habe ich die VM heruntergefahren, die VNC GPU entfernt, Nvidia wieder ausgewählt und neu gestartet. Und tada. Jetzt sehe ich auf dem Monitor ein Signal und in den Nvidia Settings ist auch ein "X Screen 0" aufgetaucht:

 

Kann Ubuntu nicht damit umgehen, wenn man zwei Grafikkarten "verbaut" hat?! Weil schlussendlich habe ich doch nichts anderes, wenn man eine vGPU und Nvidia dGPU mitgibt. Wirklich verstehen tue ich das nicht. Jedenfalls ist der Monitor nach 5 Minuten eingeschlafen und der Verbrauch steht bei 17W.

 

EDIT11:

Wie alturismo empfahl, habe ich erst das PCI Device rausgeworfen, was auch direkt die Soundkarte rauswirft:

 

Der Verbrauch sinkt dadurch zwar auf 9,8W, aber leider bleibt der C-State bei C3 hängen. Also die PCI-Verbindung scheint weiterhin aktiv zu sein.

 

Dann habe ich den rescan gemacht und die Karte ist wieder da:

 

Leider kommt es aber zu einem Fehler, wenn man die Ubuntu VM startet:

Jan  1 20:34:59 Tower kernel: vfio-pci 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x564e

Message from [email protected] at Jan  1 20:35:04 ...
 kernel:Disabling IRQ #17
Jan  1 20:35:04 Tower kernel: irq 17: nobody cared (try booting with the "irqpoll" option)
Jan  1 20:35:04 Tower kernel: CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.19.17-Unraid #2
Jan  1 20:35:04 Tower kernel: Hardware name: Gigabyte Technology Co., Ltd. C246M-WU4/C246M-WU4-CF, BIOS F4 02/03/2021
Jan  1 20:35:04 Tower kernel: Call Trace:
Jan  1 20:35:04 Tower kernel: <IRQ>
Jan  1 20:35:04 Tower kernel: dump_stack_lvl+0x44/0x5c
Jan  1 20:35:04 Tower kernel: __report_bad_irq+0x35/0xaa
Jan  1 20:35:04 Tower kernel: note_interrupt+0x1f6/0x24d
Jan  1 20:35:04 Tower kernel: handle_irq_event_percpu+0x2c/0x35
Jan  1 20:35:04 Tower kernel: handle_irq_event+0x37/0x56
Jan  1 20:35:04 Tower kernel: handle_fasteoi_irq+0x99/0x113
Jan  1 20:35:04 Tower kernel: __common_interrupt+0x9b/0xaa
Jan  1 20:35:04 Tower kernel: common_interrupt+0x96/0xc1
Jan  1 20:35:04 Tower kernel: </IRQ>
Jan  1 20:35:04 Tower kernel: <TASK>
Jan  1 20:35:04 Tower kernel: asm_common_interrupt+0x22/0x40
Jan  1 20:35:04 Tower kernel: RIP: 0010:cpuidle_enter_state+0x11b/0x1e4
Jan  1 20:35:04 Tower kernel: Code: 5b fa a1 ff 45 84 ff 74 1b 9c 58 0f 1f 40 00 0f ba e0 09 73 08 0f 0b fa 0f 1f 44 00 00 31 ff e8 9d a9 a6 ff fb 0f 1f 44 00 00 <45> 85 ed 0f 88 9e 00 00 00 48 8b 04 24 49 63 cd 48 6b d1 68 49 29
Jan  1 20:35:04 Tower kernel: RSP: 0018:ffffc9000011fe98 EFLAGS: 00000246
Jan  1 20:35:04 Tower kernel: RAX: ffff8884ac4c0000 RBX: 0000000000000001 RCX: 0000000000000000
Jan  1 20:35:04 Tower kernel: RDX: ffffe8ff00000000 RSI: ffffffff820d7be1 RDI: ffffffff820d80c1
Jan  1 20:35:04 Tower kernel: RBP: ffff8884ac4f5420 R08: 0000000000000002 R09: 0000000000000002
Jan  1 20:35:04 Tower kernel: R10: 00000000000000f1 R11: 0000000000000008 R12: ffffffff82315740
Jan  1 20:35:04 Tower kernel: R13: 0000000000000001 R14: 000011e4ebf799e9 R15: 0000000000000000
Jan  1 20:35:04 Tower kernel: ? cpuidle_enter_state+0xf5/0x1e4
Jan  1 20:35:04 Tower kernel: cpuidle_enter+0x2a/0x38
Jan  1 20:35:04 Tower kernel: do_idle+0x187/0x1f5
Jan  1 20:35:04 Tower kernel: cpu_startup_entry+0x1d/0x1f
Jan  1 20:35:04 Tower kernel: start_secondary+0xeb/0xeb
Jan  1 20:35:04 Tower kernel: secondary_startup_64_no_verify+0xce/0xdb
Jan  1 20:35:04 Tower kernel: </TASK>
Jan  1 20:35:04 Tower kernel: handlers:
Jan  1 20:35:04 Tower kernel: [<00000000fa6cd887>] vfio_intx_handler
Jan  1 20:35:04 Tower kernel: Disabling IRQ #17

 

Interrupt 17 ist die Soundkarte. Muss man evtl die Soundkarte erst rauswerfen und dann die Grafikkarte?!

 

[email protected]:~# cat /proc/interrupts
            CPU0       CPU1       CPU2       CPU3       CPU4       CPU5
   8:          0          0          0          0          0          1  IR-IO-APIC    8-edge      rtc0
   9:          0       1845          0          0          0          0  IR-IO-APIC    9-fasteoi   acpi
  16:          6          0          0          0          0          0  IR-IO-APIC   16-fasteoi   i801_smbus, vfio-intx(0000:01:00.0)
  17:          0          0          0     203571          0          0  IR-IO-APIC   17-fasteoi   vfio-intx(0000:01:00.1)

 

Ich starte mal neu...

[mgutt]

Ne, leider bekomme ich das mit dem PCI Hot-Plug nicht hin. Ich habe noch versucht die Devices einzeln zu entfernen:

 

[email protected]:~# echo 1 > /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/remove
[email protected]:~# Jan  1 20:56:05 Tower kernel: pci 0000:01:00.1: Removing from iommu group 1

[email protected]:~# echo 1 > /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/remove
[email protected]:~# Jan  1 20:56:23 Tower kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=none,decodes=io+mem:owns=io+mem
Jan  1 20:56:23 Tower kernel: pci 0000:01:00.0: Removing from iommu group 1

[email protected]:~# echo 1 > /sys/devices/pci0000:00/0000:00:01.0/remove
[email protected]:~# Jan  1 20:56:41 Tower kernel: pci_bus 0000:01: busn_res: [bus 01] is released
Jan  1 20:56:41 Tower kernel: pci 0000:00:01.0: Removing from iommu group 1

 

aber nach Aus- und Einstecken des Stromkabels und rescan:

echo 1 > /sys/bus/pci/rescan

Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0: [8086:1901] type 01 class 0x060400
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0: Adding to iommu group 1
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: [10de:2507] type 00 class 0x030000
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00ffffff]
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: reg 0x14: [mem 0x00000000-0x0fffffff 64bit pref]
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: reg 0x1c: [mem 0x00000000-0x01ffffff 64bit pref]
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: reg 0x24: [io  0x0000-0x007f]
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0007ffff pref]
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: Max Payload Size set to 256 (was 128, max 256)
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: PME# supported from D0 D3hot
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: 16.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x8 link at 0000:00:01.0 (capable of 252.048 Gb/s with 16.0 GT/s PCIe x16 link)
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: vgaarb: bridge control possible
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none
Jan  1 21:00:40 Tower kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: Adding to iommu group 1
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.1: [10de:228e] type 00 class 0x040300
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.1: reg 0x10: [mem 0x00000000-0x00003fff]
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.1: Max Payload Size set to 256 (was 128, max 256)
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.1: Adding to iommu group 1
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0: ASPM: current common clock configuration is inconsistent, reconfiguring
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0: PCI bridge to [bus 01]
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0:   bridge window [io  0x3000-0x3fff]
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0:   bridge window [mem 0x63000000-0x640fffff]
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0:   bridge window [mem 0x50000000-0x61ffffff 64bit pref]
Jan  1 21:00:40 Tower kernel: clipped [mem size 0x00000000 64bit pref] to [mem size 0xfffffffffffa0000 64bit pref] for e820 entry [mem 0x0009f000-0x000fffff]
Jan  1 21:00:40 Tower kernel: clipped [mem size 0xfffffffffffc0000 64bit pref] to [mem size 0xfffffffffffa0000 64bit pref] for e820 entry [mem 0x0009f000-0x000fffff]
Jan  1 21:00:40 Tower kernel: clipped [mem size 0x00020000 64bit pref] to [mem size 0xfffffffffffc0000 64bit pref] for e820 entry [mem 0x0009f000-0x000fffff]
Jan  1 21:00:40 Tower kernel: clipped [mem size 0x00010000 64bit pref] to [mem size 0xffffffffffff0000 64bit pref] for e820 entry [mem 0x0009f000-0x000fffff]
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0: BAR 15: assigned [mem 0x68000000-0x7fffffff 64bit pref]
Jan  1 21:00:40 Tower kernel: clipped [mem size 0x00020000] to [mem size 0xfffffffffffc0000] for e820 entry [mem 0x0009f000-0x000fffff]
Jan  1 21:00:40 Tower kernel: clipped [mem size 0x00010000] to [mem size 0xffffffffffff0000] for e820 entry [mem 0x0009f000-0x000fffff]
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0: BAR 14: assigned [mem 0x50000000-0x517fffff]
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0: BAR 13: assigned [io  0x3000-0x3fff]
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: BAR 1: assigned [mem 0x70000000-0x7fffffff 64bit pref]
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: BAR 3: assigned [mem 0x68000000-0x69ffffff 64bit pref]
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: BAR 0: assigned [mem 0x50000000-0x50ffffff]
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: BAR 6: assigned [mem 0x51000000-0x5107ffff pref]
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.1: BAR 0: assigned [mem 0x51080000-0x51083fff]
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.0: BAR 5: assigned [io  0x3000-0x307f]
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0: PCI bridge to [bus 01]
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0:   bridge window [io  0x3000-0x3fff]
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0:   bridge window [mem 0x50000000-0x517fffff]
Jan  1 21:00:40 Tower kernel: pci 0000:00:01.0:   bridge window [mem 0x68000000-0x7fffffff 64bit pref]
Jan  1 21:00:40 Tower kernel: pcieport 0000:00:01.0: AER: enabled with IRQ 122
Jan  1 21:00:40 Tower kernel: pci 0000:01:00.1: D0 power state depends on 0000:01:00.0

 

 

kommt es zum selben Fehler:

 

[email protected]:~# virsh start Ubuntu22
Jan  1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none
Jan  1 21:02:10 Tower kernel: br0: port 2(vnet1) entered blocking state
Jan  1 21:02:10 Tower kernel: br0: port 2(vnet1) entered disabled state
Jan  1 21:02:10 Tower kernel: device vnet1 entered promiscuous mode
Jan  1 21:02:10 Tower kernel: br0: port 2(vnet1) entered blocking state
Jan  1 21:02:10 Tower kernel: br0: port 2(vnet1) entered forwarding state
Jan  1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
Jan  1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap [email protected]
Jan  1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap [email protected]
Jan  1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap [email protected]
Jan  1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap [email protected]
Jan  1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap [email protected]
Jan  1 21:02:10 Tower kernel: vfio-pci 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x564e
Jan  1 21:02:10 Tower kernel: vfio-pci 0000:01:00.1: enabling device (0000 -> 0002)
Jan  1 21:02:11 Tower kernel: vfio-pci 0000:01:00.1: vfio_ecap_init: hiding ecap [email protected]
Domain 'Ubuntu22' started

[email protected]:~# Jan  1 21:02:11 Tower  avahi-daemon[3680]: Joining mDNS multicast group on interface vnet1.IPv6 with address fe80::fc54:ff:fee3:8fe8.
Jan  1 21:02:11 Tower  avahi-daemon[3680]: New relevant interface vnet1.IPv6 for mDNS.
Jan  1 21:02:11 Tower  avahi-daemon[3680]: Registering new address record for fe80::fc54:ff:fee3:8fe8 on vnet1.*.
Jan  1 21:02:11 Tower kernel: vfio-pci 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x564e

Message from [email protected] at Jan  1 21:02:16 ...
 kernel:Disabling IRQ #17
Jan  1 21:02:16 Tower kernel: irq 17: nobody cared (try booting with the "irqpoll" option)
Jan  1 21:02:16 Tower kernel: CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.19.17-Unraid #2
Jan  1 21:02:16 Tower kernel: Hardware name: Gigabyte Technology Co., Ltd. C246M-WU4/C246M-WU4-CF, BIOS F4 02/03/2021
Jan  1 21:02:16 Tower kernel: Call Trace:
Jan  1 21:02:16 Tower kernel: <IRQ>
Jan  1 21:02:16 Tower kernel: dump_stack_lvl+0x44/0x5c
Jan  1 21:02:16 Tower kernel: __report_bad_irq+0x35/0xaa
Jan  1 21:02:16 Tower kernel: note_interrupt+0x1f6/0x24d
Jan  1 21:02:16 Tower kernel: handle_irq_event_percpu+0x2c/0x35
Jan  1 21:02:16 Tower kernel: handle_irq_event+0x37/0x56
Jan  1 21:02:16 Tower kernel: handle_fasteoi_irq+0x99/0x113
Jan  1 21:02:16 Tower kernel: __common_interrupt+0x9b/0xaa
Jan  1 21:02:16 Tower kernel: common_interrupt+0x96/0xc1
Jan  1 21:02:16 Tower kernel: </IRQ>
Jan  1 21:02:16 Tower kernel: <TASK>
Jan  1 21:02:16 Tower kernel: asm_common_interrupt+0x22/0x40
Jan  1 21:02:16 Tower kernel: RIP: 0010:cpuidle_enter_state+0x11b/0x1e4
Jan  1 21:02:16 Tower kernel: Code: 5b fa a1 ff 45 84 ff 74 1b 9c 58 0f 1f 40 00 0f ba e0 09 73 08 0f 0b fa 0f 1f 44 00 00 31 ff e8 9d a9 a6 ff fb 0f 1f 44 00 00 <45> 85 ed 0f 88 9e 00 00 00 48 8b 04 24 49 63 cd 48 6b d1 68 49 29
Jan  1 21:02:16 Tower kernel: RSP: 0018:ffffc9000011fe98 EFLAGS: 00000246
Jan  1 21:02:16 Tower kernel: RAX: ffff8884ac4c0000 RBX: 0000000000000001 RCX: 0000000000000000
Jan  1 21:02:16 Tower kernel: RDX: ffffe8ff00000000 RSI: ffffffff820d7be1 RDI: ffffffff820d80c1
Jan  1 21:02:16 Tower kernel: RBP: ffff8884ac4f5420 R08: 0000000000000002 R09: 0000000000000002
Jan  1 21:02:16 Tower kernel: R10: 00000000000000f1 R11: 0000000000000008 R12: ffffffff82315740
Jan  1 21:02:16 Tower kernel: R13: 0000000000000001 R14: 0000013681b08cc0 R15: 0000000000000000
Jan  1 21:02:16 Tower kernel: ? cpuidle_enter_state+0xf5/0x1e4
Jan  1 21:02:16 Tower kernel: cpuidle_enter+0x2a/0x38
Jan  1 21:02:16 Tower kernel: do_idle+0x187/0x1f5
Jan  1 21:02:16 Tower kernel: cpu_startup_entry+0x1d/0x1f
Jan  1 21:02:16 Tower kernel: start_secondary+0xeb/0xeb
Jan  1 21:02:16 Tower kernel: secondary_startup_64_no_verify+0xce/0xdb
Jan  1 21:02:16 Tower kernel: </TASK>
Jan  1 21:02:16 Tower kernel: handlers:
Jan  1 21:02:16 Tower kernel: [<00000000476faa67>] vfio_intx_handler
Jan  1 21:02:16 Tower kernel: Disabling IRQ #17

 

EDIT1:

Demnach dürfte "remove" nicht ausreichend sein:

https://www.kernel.org/doc/Documentation/filesystems/sysfs-pci.txt

The 'remove' file is used to remove the PCI device, by writing a non-zero integer to the file.
This does not involve any kind of hot-plug functionality, e.g. powering off the device.
The device is removed from the kernel's list of PCI devices, the sysfs directory for it is removed, 
and the device will be removed from any drivers attached to it. Removal of PCI root buses is disallowed.

 

Und wenn ich diese Präsentation richtig verstehe, dann kann Unraid kein Hot-Plug, weil es schlicht nicht aktiv ist:

[email protected]:~# grep HOT /usr/src/linux-*/.config
CONFIG_TICK_ONESHOT=y
CONFIG_HOTPLUG_CPU=y
# CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set
# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_HOTPLUG_MEMORY=y
CONFIG_ACPI_HOTPLUG_IOAPIC=y
CONFIG_HOTPLUG_SMT=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_MEMORY_HOTPLUG=y
# CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE is not set
CONFIG_MEMORY_HOTREMOVE=y
# CONFIG_HOTPLUG_PCI is not set
CONFIG_DM_SNAPSHOT=m
# CONFIG_USB_STORAGE_JUMPSHOT is not set
CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
CONFIG_XEN_MEMORY_HOTPLUG_LIMIT=512
# CONFIG_WIRELESS_HOTKEY is not set
# CONFIG_SURFACE_HOTPLUG is not set
# CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set
# CONFIG_TRACER_SNAPSHOT is not set

 

Laut der Präsentation braucht es dafür nämlich die Kernel Configs:

CONFIG_HOTPLUG_PCI_PCIE=y

CONFIG_HOTPLUG_PCI=y

 

Ich probiere jetzt schon mal diese Kernel Flags, vielleicht hilft es ja:

pci=realloc,assign-busses,use_crs

 

EDIT2:

Nein, hilft leider auch nicht. Ich denke die Rahmenbedingungen erlauben das einfach nicht.