Treiber- und Firmwaregrundlagen

Erkannt, gebunden, funktionsfähig: drei verschiedene Befunde

Ordne PCI-/USB-Auflistung, Treiber-Probe und Laufzeitbindung ein, bevor du einen Treiberkandidaten bewertest.

Eine Auflistung benennt nur einen Busbefund

Ein numerisches PCI- oder USB-Paar belegt eine gemeldete Kennung. Es beschreibt nicht jede Platinenrevision, jedes Kabel, Display, jede Antenne oder jeden Stromzustand. Ein lesbarer Name im Bericht bleibt eine gemeldete Bezeichnung. Der Explorer gleicht eine kuratierte Familie mit Quellen ab und erhält Unsicherheit bei gemeinsam genutzten Kennungen.

lspci -nnk
lsusb

Auf einen Match folgt ein Probe-Vorgang

Eine Upstream-ID-Tabelle beschreibt eine Kandidatenbeziehung. Der installierte Kernel muss den Treiber enthalten, seine Konfiguration muss ihn zulassen und der Probe-Vorgang muss gelingen. Firmwareladung, Plattformabhängigkeiten oder eine absichtliche Überschreibung können die Bindung verändern. Ein Modul auf der Platte oder in lspci ist nicht dasselbe wie Kernel driver in use.

Die tatsächliche Bindung lesen

Bei einem PCI-Endgerät hält der sysfs-Treiberlink die Bindung dieses Systems fest. Nutze Domain, Bus, Gerät und Funktion aus deiner Ausgabe. Eine fehlende Zeile in einem gekürzten Bericht bleibt unberichtet. Ein ausdrückliches unclaimed ist stärker. vfio-pci auf einem Host kann beabsichtigtes Passthrough statt eines defekten nativen Treibers sein.

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

Quellen

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

Lokales Erkennungswerkzeug nutzen