Dennis HilkLinux-DiagnoseEN

Chipsätze und PCIe

PCIe-Switch-Port-Kontext

Verfolge den Upstream-/Downstream-Switchpfad, bevor ein ausgehandelter Link oder AER-Ereignis einem Endgerät zugeschrieben wird.

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

Dies ist ein allgemeiner PCIe-Brücken-/Treiberkontext, keine exakte Switch-Hersteller-ID. Das Kernel-Probe umfasst PCIe-Upstream- und Downstream-Typen. Ein Baum mit mehreren Schritten kann getrennte Links mit unterschiedlichen Geschwindigkeiten und Breiten enthalten; Switchfunktion und nachgeschaltete GPU sind eigene PCI-Funktionen.

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

pcieport ist bei Bindung des eingebauten Port-Bustreibers der Portbesitzer. AER und Downstream-Containment sind Dienste der Hierarchie und keine GPU-Treiber. Lies beide Seiten des betroffenen Links; das Maximum des Endgeräts misst weder den Switch-Uplink noch garantiert es den aktuell ausgehandelten Pfad.

  • 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-Switch-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

Ein Brückenklassentreffer umfasst auch Geräte anderer Art. Hersteller, Mainboardmodell, Riserdesign und PCIe-Generation werden ohne ausdrückliche Capability- und Gerätebelege des eingefügten Berichts nicht abgeleitet.

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.