Dennis HilkLinux-DiagnoseEN

Chipsätze und PCIe

PCIe-Root-Port-Kontext

Ein Kontext für Topologie und native Dienste; die Brückenklasse allein belegt weder genaues Mainboard noch Porttyp.

Redaktionelle Quellenprüfung: Öffentliches Profil teilenIm Erkennungswerkzeug öffnen
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

Dieses Profil besitzt keinen exakten Hersteller-/Gerätetreffer. Der geprüfte Treiber akzeptiert PCI-Brückenklassen, verlangt anschließend aber einen PCIe-Root-, Upstream-, Downstream- oder RCEC-Typ. Ein Root Port ist der plattformseitige Elternknoten eines Links; er ist vom GPU- oder Speicherendgerät zu unterscheiden, dessen Fehler später im Bericht erscheint.

Dies ist ausdrücklich ein Klassen-, Transport- oder Treiberkontextprofil. Es identifiziert kein exaktes numerisches Produkt.

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

Treiber und Bindung

Der beobachtete Treibername ist pcieport. PCIEPORTBUS ist bei Aktivierung fest in den Kernel eingebaut; ein fehlendes ladbares Modul namens pcieport ist daher kein Fehler. Dienste wie AER hängen von eigener Kernelkonfiguration und Firmwarekontrolle ab, nicht allein vom sichtbaren Brückengerät.

  • pcieport — Kernel-Treiber-/Modulkandidat (fest eingebauter Code möglich)

Erkannt, gebunden, funktionsfähig: Unterschiede verstehen

Firmware

Hier keine Host-Datei belegt

Die Porttreiberquellen belegen keinen externen Firmwarenamen. Systemfirmware legt weiterhin Plattformpolitik fest und kann PCIe-Dienste selbst kontrollieren; die Linux-AER-Zuständigkeit hängt von der dokumentierten Übergabe zwischen Firmware und Betriebssystem ab. „Kein Dateiname“ behauptet nicht, dass die Brücke ohne Firmware auskommt.

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 PCIe-Root-Port-Kontext. 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.

PCIe-Capability-Typ und Linkinformationen lesen

sudo lspci -vv -s BDF

Erhöhte Rechte können nötig sein. Hier wird PCI-Konfiguration gelesen, nicht geändert. sudo dient Capability-Details, die unprivilegierte Konfigurationszugriffe möglicherweise ausblenden. Prüfe Root-Port-/Upstream-/Downstream-/RCEC-Typ und trenne LnkCap von LnkSta; eine maximale Fähigkeit ist nicht der ausgehandelte Zustand.

PCI-Eltern-/Kindbaum lesen

lspci -t

Diese Topologieübersicht braucht normalerweise kein sudo. Ordne BDF zunächst Elternknoten und nachgeschalteten Funktionen zu, bevor du einen AER-Bericht einordnest. Ein Baum belegt Verbindungen, nicht Leistung oder Linkqualität.

Controllermeldungen des aktuellen Starts lesen

journalctl -k -b --no-pager

Halte erstes AER-Ereignis, Schweregrad, meldende Adresse und Wiederherstellungsfolge zusammen fest. Der Journalzugriff kann eine lokale Gruppenmitgliedschaft benötigen; fehlende Leserechte sind kein Controllerfehler.

Grenzen und passende Fehlerhilfen

Bestätige über Capability-Typ und Topologie, dass die gefundene Brücke wirklich ein Root Port ist. Korrigierte AER-Zähler beschreiben beobachtete Linkereignisse und diagnostizieren keine defekte CPU, Platine oder angeschlossene GPU.

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.