Chipsätze und PCIe

Intel VMD mit eigener PCI-Domain

Ein tabellenbelegtes Intel-VMD-Controllerprofil, das Controller und nachgeschalteten Speicher getrennt einordnet.

Auf dieser Seite
  1. Überblick und Identität
  2. Treiber und Bindung
  3. Firmware
  4. Lesende Diagnose
  5. Grenzen und passende Fehlerhilfen
  6. Quellen

Überblick und Identität

Die geprüften serverorientierten Einträge besitzen Memory-BAR-Shadow-Funktionen; 28c0 hat zusätzlich Behandlung von Busbeschränkungen. Der Quelltext belegt VMD-Controllerverhalten, kein konkretes Servermainboard und keine bestimmten NVMe-Geräte hinter der umgeordneten Domain.

Kuratierte Kennungen
pci 8086:201d pci 8086:28c0

Ein numerischer Match belegt eine Kandidatenfamilie im geprüften Quellenrahmen. Verkaufsnamen, Platinenvarianten, Subsystembedingungen und erfolgreiche Funktion bleiben getrennte Fragen.

Treiber und Bindung

vmd erzeugt und verwaltet eine PCI-Hierarchie hinter dem Controller. Speicherendgeräte behalten eigene Kerneltreiber; VMD-Controller und NVMe-Namespace sind somit unterschiedliche Ebenen. Ein in der Initramfs fehlendes Laufwerk kann mit der Controllerverfügbarkeit zusammenhängen, obwohl der NVMe-Treiber vorhanden ist. Erfasse beide Ebenen vor dieser Schlussfolgerung.

  • vmd — Kernel-Treiber-/Modulkandidat

Erkannt, gebunden, funktionsfähig: Unterschiede verstehen

Firmware

Hier keine Host-Datei belegt

Der geprüfte VMD-Quelltext definiert Controllerfunktionen und PCI-Hierarchie, aber kein allgemeines externes Firmware-Abbild für diese IDs. Plattformfirmware bestimmt die vorhandene Aufzählungs-/Speicherpolitik. Kein hier belegter Host-Dateiname bedeutet nicht, dass Mainboard oder Laufwerke ohne Firmware auskommen.

Firmwarepakete deiner Distribution prüfen

Lesende Diagnose

Führe jeden angezeigten Befehl einzeln aus. Ersetze Großbuchstaben-Platzhalter durch betroffenes Gerät, Schnittstelle oder Modul aus deiner Ausgabe. Hier wird nichts ausgeführt. Auch lesende Ausgaben können private Kennungen enthalten.

Funktion und gebundenen Treiber lesen

lspci -nnk -s BDF

Ersetze BDF durch die Adresse der Funktion Intel VMD mit eigener PCI-Domain. Die Übersicht braucht normalerweise kein sudo. Numerische ID und „driver in use“ sind stärkere Belege als ein beschreibender Name oder eine Kandidatenliste.

PCI-Treiberbesitzer bestätigen

readlink /sys/bus/pci/devices/BDF/driver

Nutze die vollständige BDF-Form domain:bus:slot.function. Der Befehl braucht normalerweise kein sudo und liest nur einen Link. Die letzte Komponente nennt den gebundenen Treiber; kein Link beschreibt eine ungebundene/fehlende Funktion, kein fehlendes Softwarepaket.

Umgeordnete PCI-Domains lesen

lspci -D -t

Dieser nur gelesene Baum benötigt normalerweise kein sudo. Behalte Domainnummern bei der Zuordnung von Controller und Endgeräten bei. Ein sichtbarer VMD-Elternknoten ist weder die NVMe-Treiberbindung noch ein Beweis, dass das Root-Dateisystem beim Booten gefunden wird.

Controllermeldungen des aktuellen Starts lesen

journalctl -k -b --no-pager

Ordne VMD-Initialisierung und nachfolgende nvme-/Geräteerkennung der Bootfehlerfolge zu. Der Journalzugriff kann eine lokale Gruppenmitgliedschaft benötigen; fehlende Leserechte sind kein Controllerfehler.

Grenzen und passende Fehlerhilfen

Die Controller-IDs belegen weder RAID-Politik noch genaues NVMe-Modell oder benötigten Treiber in der Boot-Initramfs. Es werden weder BIOS-Speichermodusänderung, Unbinding, Rescan noch Schreibzugriff ausgeführt; ein fehlendes Laufwerk braucht weiterhin eigene Geräte- und Bootbefunde.

Diese Anleitungen passen zu relevanten Befunden und behaupten keinen Fehler bei jedem Gerät dieser Familie.

Hardware-Diagnoseweg wählen · Log-Auszug im Fix Lab prüfen

Quellen

Eine Quellenprüfung hält geprüfte Implementierung oder Dokumentation fest, keinen reproduzierten Hardwaretest. Versionsbezogene Tabellen belegen weder Mindestkernel noch garantierte Funktion.