Dieser Beitrag ist erschienen in freiesMagazin (Link) 11/2009 / Lizenz: GNU Free Documentation License (GNU FDL) (Link) / Autor: Rainer König.
Wenn Sie diesen Artikel weiterverwenden möchten, beachten Sie bitte die Lizenzbedingungen. Vielen Dank.
Hardwarekompatibilität unter Linux
von Rainer König
Trotz des folgenden Zitats fürchten sich Linux-Nutzer bei jeder Neuanschaffung vor Problemen mit der neuen Hardware und Umsteiger von Windows zittern vor der Frage, ob ihr bestehendes System denn tatsächlich unter Linux laufen wird: „Linux supports more devices 'out of the box' than every other operating system ever has“ (Greg Kroah-Hartman, Keynote zum Ottawa Linux Symposium 2006).
Generelle Probleme
Offensichtlich gibt es auch im Zeitalter von Plug & Play noch jede Menge Fallstricke und Stolpersteine, die dem Linux-Anwender den Spaß verderben können.
Das Babylon der Neuzeit
Eines der größten Probleme bei der Neuanschaffung von Hardware ist, dass es im IT-Sektor nur so von „Buzzwords“ wimmelt. Man kauft heute PCs mit Markenbezeichnungen, ohne tatsächlich zu verstehen, welche Hardware den Computer „unter der Haube“ antreibt. Selbst wenn man hier Details sucht, wird man hoffnungslos mit seltsam klingenden Begriffen überhäuft. Wer weiß, was der Unterschied zwischen „Nehalem“ und „Core i7“ ist? Oder ob „Q45“ das gleiche ist wie „Tylersburg?“ Oder welcher Hardwarechip sich auf der „Intel Gigabit Ethernet LAN“-Karte befindet, die sich „onboard“ auf dem Mainboard des neuen Rechners befinden soll. Und dann, ob dieser Chip tatsächlich schon von Linux unterstützt wird? Ein weiteres Problem ist, dass sich die Hersteller vorbehalten, auch mal was an der Hardware zu ändern, ohne das groß zu verkünden. Kann man sich sicher sein, dass die Webcam, die man am Nachmittag beim Elektronik-Discounter kaufen will, die gleichen Chips enthält, wie die Webcam mit dem gleichen Namen, für die man im Internet einen sehr positiven Erfahrungsbericht gefunden hat, der allerdings schon zwölf Monate alt ist?
Hardware und Zubehör werden gerade im Desktop-Bereich immer noch für das Betriebssystem mit dem größten Marktanteil entwickelt, nämlich Microsoft Windows. Entsprechend aussagekräftig sind dann auch die Verkaufsverpackungen gestaltet. Man liest, dass die Hardware wohl jetzt auch mit Vista läuft, zur Linux-Verwendbarkeit findet man aber in den wenigsten Fällen Hinweise.
Um hier eine Veränderung zu bewirken, bedarf es massiver Anstrengung der Community. Zum einen kann man Hersteller, die explizit auch auf die Verwendbarkeit unter Linux hinweisen, durchaus mal eine lobende E-Mail schicken, damit die sehen, dass Kunden das Produkt eben auch wegen der Linux-Kompatibilität gekauft haben. Zum anderen muss man Hersteller, die Linux ignorieren, auch mal darauf hinweisen, dass sie angesichts dieser Ignoranz bei der Kaufentscheidung nicht berücksichtigt wurden.
Open Source vs. Proprietär
Wenn ein Hersteller dann Linux-Kompatibilität zusichert, ist die nächste Frage, ob der zum Betrieb der Hardware notwendige Treiber ein Open-Source-Treiber ist, also unter der GPL steht und im Kernel gepflegt wird, oder ob es sich hier um einen sogenannten proprietären Treiber handelt, also Closed Source, der nur vom Hersteller gewartet werden kann. Für den Nur-Anwender, der möchte, dass sein System läuft, mag dieser Unterschied zunächst irrelevant erscheinen. Trotzdem sollte man folgende Konsequenzen beim Einsatz von proprietären Treibern bedenken:
Schlecht gepflegte proprietäre Treiber können beim nächsten Kernel-Update zu massiven Problemen führen, weil der dann aktualisierte Kernel vielleicht eine marginale ABI-Änderung (Application Binary Interface) mitbringt, die mit dem Treibermodul inkompatibel ist.
Support für Closed-Source-Treiber wird von den Leuten und Firmen im Open-Source-Umfeld eher ungern geleistet oder kann mangels Einblick in die Quellen des Treibers gar nicht geleistet werden. In so einem Fall wird man dann aufgefordert zu beweisen, dass das Problem auch ohne den proprietären Treiber existiert, was sich sehr schwierig gestalten kann, wenn der proprietäre Treiber fundamentale Funktionen wie beispielsweise den Zugriff auf die Festplatte bereitstellt. Entfernt man diesen Treiber, wird das System nicht mehr funktionieren und man kann somit nicht den Beweis antreten, dass der proprietäre Treiber nicht am Problem beteiligt ist.
Proprietäre Treiber werden eigentlich aktuell nur für die Graphikkarten von nVidia und ATI eingesetzt, wobei man anmerken muss, dass hier auch bereits an Open-Source-Treibern gearbeitet wird. Wer aber beispielsweise gerne mit FlightGear spielt, wird höchstwahrscheinlich auf die beschleunigten OpenGL-3D-Treiber dieser Firmen zurückgreifen. Da zudem beispielsweise der nVidia-Treiber so gekapselt ist, dass der eigentliche proprietäre Treiber mittels eines quelloffenen Schnittstellenmoduls an den Kernel angeflanscht wird, ist hier die Gefahr einer inkonsistenten ABI eher gering, weil die Stabilität der ABI in Richtung Closed-Source-Teil vom Open-Source-Kernelmodul sichergestellt wird. Dieser Treiber und das zugehörige Kernelmodul wird auch oft über Repositorys für verschiedene Distributionen als installierbares Paket angeboten.
Vanilla vs. Distribution
Ein anderer Fallstrick auf dem Weg zur Linux-Kompatibilität ist, dass es eben nicht „das Linux“ gibt. Kommt ein Hersteller mit einem neuen Siliziumchip auf den Markt und will dafür Treiber bereitstellen, dann ist der logische und sinnvolle Übergabepunkt der „Vanilla-Kernel“ bei Kernel.org. Treiber, die hier eingebunden sind, werden bei Aktualisierungen des Kernels automatisch ebenfalls aktualisiert. Wenn also beispielsweise der Treiber für die LAN-Karte im Kernel 2.6.27 dazu kam, dann wird dieser Treiber auch in den Folgeversionen 2.6.28, 2.6.29 usw. enthalten sein. Der Linux-Anwender kann damit relativ sicher sein, dass seine Hardware auch nach Aktualisierungen nicht aufhört zu funktionieren, es sei denn er nutzt noch Hardware aus der PC-Steinzeit, denn hin und wieder werden solche prähistorischen Treiber auch mal aus dem Kernel entfernt, weil die Kernelentwickler zu der Annahme gekommen sind, dass niemand auf der Welt diese Hardware noch benutzt.
Ein weiteres Problem ergibt sich daraus, dass der normale Linux-Anwender eben genau nicht den Vanilla-Kernel benutzt, sondern den Kernel, der mit seiner Distribution installiert wurde. Eine logische Konsequenz ist: Wenn man neue Hardware nutzen will, muss man auch neue Versionen der Distributionen einsetzen. Ein SUSE 10.0 von 2005 enthält einen Kernel, der natürlich keine Hardware wie den Boazman-Gigabit-LAN-Chip aus dem Jahr 2008 unterstützt.
Trotzdem kann man auch mit „aktuellen“ Distributionen noch manche Bauchlandung in Sachen Hardwarekompatibilität hinlegen. Debian Lenny nutzt beispielsweise noch den Kernel 2.6.26, was bedeutet, dass auf sehr neuen Geräten eben Dinge wie der oben erwähnte LAN-Chip noch nicht funktionieren, weil deren Treibercode erst im Kernel 2.6.27 hinzukam.
Dieses Problem ist den Kernel-Entwicklern durchaus bewusst und so geben sich die Distributoren wie Novell und Red Hat für ihre Enterprise-Distributionen sehr viel Mühe, neue Treiber in die vergleichsweise alten Kernel einfließen zu lassen. So enthält ein Red Hat Enterprise Linux 5.4 zwar immer noch einen auf der Version 2.6.18 basierenden Kernel, die Treibermodule für moderne Hardware sind aber trotzdem vorhanden.
Manchmal scheitert dieses „Backporting“ allerdings auch an dem Umstand, dass sich die ABI im Kernel so gewaltig verändert hat, dass ein neuerer Code nur mit irrsinnigem Aufwand in alte Kernel eingebracht werden könnte. Beispielsweise enthält Red Hat Enterprise Linux wenig Anpassungen für WLAN-Karten, eben weil sich seit 2.6.18 das komplette WLAN-Subsystem so gravierend geändert hat, dass sich keiner den Aufwand für einen Backport auferlegen will.
Selbsthilfe
Kompatibilitätslisten
Die zentrale Anlaufstelle zum Thema Linux-Treiber im Internet findet man auf der Seite von Linux-Drivers.org [1]. Hier gibt es eine ganze Menge Links zu weiteren Kompatibilitätslisten und jede Menge Informationen zum Thema Linux-Treiber.
Allerdings muss man sich auch vergegenwärtigen, dass viele dieser Kompatibilitätslisten nicht sehr umfassend sind und jede von Freiwilligen gepflegte Datenbank mit Kompatibilitätsinformationen nur so gut sein kann, wie das, was die Benutzer dort hineinschreiben.
Daher muss man an die Nutzer appellieren, auch mal ein paar Minuten zu spendieren, um solche Informationen zu einem Gerät einzutragen. Andere Nutzer werden davon profitieren und man selbst profitiert von den gut dokumentierten Einträgen der anderen.
Zertifizierungen
Im Geschäftsumfeld legen viele Kunden Wert auf zertifizierte Systeme. Die Distributoren Novell und Red Hat bieten hierfür Hardware-Zertifizierungsprogramme an, bei denen meist komplette Systeme auf ihre Linux-Kompatibilität hin getestet werden.
Bei Red Hat wird hierbei ein komplettes System mit allen möglichen Bestelloptionen qualifiziert, bevor es einen Eintrag in der Red Hat HCL [2] erhält. Das bedeutet, ein System, welches beispielsweise mit fünf verschiedenen Grafikkarten bestückt werden kann, muss auch mit allen diesen Grafikkarten getestet werden, um als zertifiziert zu gelten. Um Arbeit zu sparen, können hier auch bereits bestandene Tests auf anderen Systemen mit diesen Grafikkarten referenziert werden. Red Hat garantiert mit der Zertifizierung, dass dieses System mit allen Bestelloptionen von der zertifizierten Red-Hat-Enterprise-Linux-Version „out-of-the-box“ unterstützt wird. Das führt allerdings auch dazu, dass High-End-Grafikkarten wie die nVidia Quadro FX5800 im Zertifizierungstest mit dem VESA-Treiber anstelle des proprietären nVidia-Treibers getestet werden.
Novell geht mit seinen „Bulletins“ für SUSE Linux Enterprise Desktop oder Server einen geringfügig anderen Weg. Hier wird ein genau spezifiziertes System in einem Ausbauzustand getestet. Werden alle Tests bestanden, dann erhält dieses System ein sogenanntes Bulletin im Novell Bulletin System und kann über die Suchseite [3] gefunden werden. Da beim SUSE Linux Enterprise Desktop mittlerweile auch die 3-D-Desktop-Effekte wie der rotierende Würfel mitgetestet werden, kann hier auch zum Test der proprietäre nVidia-Treiber benutzt werden. Wird ein Computer in drei Ausbauvarianten getestet, so gibt es nach erfolgreichen Tests entsprechend drei Bulletins, welche dies dokumentieren.
Newsgroups und Foren
Ein weiterer Anlaufpunkt für Hilfesuchende sind Newsgroups im deutschen Usenet, wie etwa de.comp.os.unix.linux.hardware oder entsprechende Webforen. Bevor man hier aber munter Fragen in die Runde wirft, sollte man zum einen schon mal einen Blick in die oben erwähnten Kompatibilitätslisten geworfen haben und zum anderen die Hinweise „Wie man Fragen richtig stellt“ [4] beherzigen. Leute aus der Communitiy helfen gerne weiter, wenn man in der Lage ist, sein Problem entsprechend zu artikulieren. Und sollte man eine Frage gestellt haben und dann doch selbst die Lösung gefunden haben, dann sollte man schildern, welche Maßnahmen zur Lösung geführt haben, denn das hilft dem nächsten Suchenden unter Umständen schon einen großen Schritt weiter.
Sonstiges
Kauft man seine Hardware oder Erweiterungen statt beim Billig-Discounter beim örtlichen Fachhandel, dann können einem die Leute dort eventuell bei Fragen bereits die notwendigen Auskünfte geben. Je nach dem was man erwerben will, kann es auch nützlich sein, einfach ein Notebook mit Linux mitzubringen, um direkt im Geschäft ausprobieren zu können, ob das neue USB-Gadget auch mit Linux-Treibern versorgt ist.
Kernel-Treiber Grundlagen
Wenn es wirklich ans Eingemachte geht, dann hilft oft ein grundlegendes Verständnis davon, wie Gerätetreiber funktionieren.
Device-IDs ermittlen mit lspci / lsusb
Im Zeitalter von Plug & Play haben Hardware-Erweiterungen standardisierte Schnittstellen, um dem System mitzuteilen, „wer“ sie sind. Bei Erweiterungskarten passiert das im Allgemeinen über die sogenannte PCI-ID, bei USB ist der Mechanismus ähnlich.
Mit Befehlen wie lspci oder lsusb kann man sich so sehr schnell einen Überblick über die im System vorhandenen PCI-Erweiterungskarten oder angeschlossene USB-Geräte verschaffen.
Die aufgelisteten Geräte werden über ihre PCI/USB-ID identifiziert. Eine Device-ID besteht aus 4 Bytes, 2 Bytes welche die sogenannte Vendor-ID (Hersteller-ID) enthalten und zwei Bytes für die Device-ID (also die Gerätekennung). Zudem gibt es noch Klassen-IDs für verschiedene Geräteklassen, Subvendor-IDs und Subdevice-IDs. Letztere kommen zum Einsatz, wenn z. B. ein Intel LAN Chip auf einem Mainboard von DELL verbaut wird. Dann hat dieser Chip die Vendor-ID 8086 (Intel) und die Subvendor-ID 1028 (Dell).
Die Textbeschreibungen kommen dabei aus Dateien wie /usr/share/misc/pci.ids. Dort ist unter dem Schlüssel der binären PCI-ID ein Text hinterlegt. Findet die Nachschlagefunktion keine Beschreibung, dann gibt sie „unknown device“ zurück. Dies sagt lediglich aus, dass die Datei mit den PCI-ID-Beschreibungen veraltet ist und macht definitiv keinerlei Aussage über die Treiberunterstützung für das jeweilige Gerät.
Eine neuere Version der PCI-ID-Beschreibungsdatei kann man bei Sourceforge [5] runterladen.
Informationen über Kernel-Module erhalten
Mit dem Programm modinfo kann man sich Informationen über Kernelmodule beschaffen. Jedes Kernelmodul hat, sofern es sich um einen PCI- oder USB-Gerätetreiber handelt, prinzipiell die gleiche (hier grob beschriebene) Struktur:
- Beim Laden bzw. Initialisieren des Moduls macht dieses ganz abstrakt das Gleiche wie das Programm lspci.
- Für jedes zurückgelieferte Gerät vergleicht das Modul nun, ob die Vendor- und Device-ID in der Tabelle der Geräte enthalten ist, die das Modul „kennt“.
- Für jedes gefundene Gerät wird dann ein „Device-Node“ angelegt, mit dem das Gerät angesprochen werden kann. Notwendige Initialisierungen von Chip-Registern werden vorgenommen.
- Werden keine vom Modul unterstützten Geräte gefunden, dann verbleibt das Modul inaktiv im Speicher.
Besonders der letzte Punkt führt oft zu Fehlinterpretationen. Man liest immer wieder in den Newsgroups, dass der Treiber ja „keine Fehlermeldung“ bringt und deswegen eigentlich funktionieren sollte. Dabei wird gerne übersehen, dass man auf einem beliebigen System auch andere Treiber laden kann, ohne dass eine Fehlermeldung erfolgt.
Wenn man modinfo z. B. für das Modul sata_via aufruft, bekommt man folgende Ausgabe:
# modinfo sata_via |
Für dieses Beispiel sind besonders die Zeilen mit alias: interessant. Eine genaue Beschreibung, wie diese Zeilen zu interpretieren sind, findet man im Wiki von Arch-Linux [6]
.
Hier die Auflistung der PCI-Geräte des Beispielrechners:
# lspci |
Oder genauer das Gerät auf Bus 0:0f.0:
# lspci -s 0:f.0 -n |
Der SATA-RAID-Controller im Beispiel hat also die Vendor-Device-ID-Kombination 1106:3149. Schaut man die Ausgabe von modinfo sata_via nochmals genau an, dann sieht man diese Werte in der fünften Alias-Zeile. Das bedeutet, das Modul sata_via wird beim Abklappern der PCI-Geräte auf genau diesen RAID-Controller stoßen und sich zuständig fühlen.
Woher der Kernel weiß, welches Modul er braucht
Nun stellt man sich natürlich die Frage, woher denn der Kernel weiß, dass er für den SATA-Controller genau dieses Modul braucht. In den „module init tools“ gibt es das Kommando depmod, welches die Nachschlagedateien unter /lib/modules/<kernelversion>/, wie z. B. die Datei modules.pcimap, erzeugt. Hierzu wird für jedes Modul unter /lib/modules/<kernelversion> sozusagen ein modinfo aufgerufen und die Werte der gefundenen Alias-Zeilen werden in die entsprechende Nachschlagetabelle eingetragen. Für den Beispiel-SATA-Controller kann dann z. B. so der Treiber ermittelt werden:
# grep 0x00003149 /lib/modules/2.6.26-2-amd64/modules.pcimap | grep 1106 |
Der erste grep sucht nach der Device-ID und der zweite nach dem Pipe-Symbol filtert noch die Vendor-ID aus. Übrig bleibt genau eine Zeile mit dem Eintrag für sata_via. Bingo! So erkennt der Kernel also, welches Modul zu laden ist.
Noch ein Beispiel, diesmal mit einer LAN-Karte. Die ersten beiden Zeilen ermitteln wie gehabt die PCI-ID. Dann schlägt man in der modules.pcimap den benötigten Treiber nach.
# lspci -s 0:c.0 |
Hier wird man mit drei Einträgen überrascht. Zweimal für den Treiber 8139too und einmal für den Treiber 8139cp. Der zweite Eintrag für 8139too heißt letztlich nur, dass das Modul 8139too zuständig ist, wenn die Device-ID 8139 ist und Subvendor-ID 10ec und Subdevice-ID 8139 - egal welche Vendor-ID das Gerät hat.
Für diese LAN-Karte gibt es also zwei konkurrierende Treiber. Mittels lsmod kann man nachsehen, welche Treiber geladen sind:
# lsmod | grep 8139 |
In diesem Beispiel sind also beide Treibermodule geladen. Welcher Treiber wird aber nun benutzt? Um das herauszufinden kann man die Ausgabe von lspci ein wenig mehr „gesprächig“ (verbose) machen:
# lspci -s 0:c.0 -v |
Die vorletzte Zeile zeigt, dass aktuell das Modul 8139too die Karte betreibt. Man kann nun zum Beispiel die Kernel-Meldungen nach Mitteilungen von 8139cp durchsuchen:
# dmesg | grep 8139cp |
Das Modul 8139cp hat also beim noch genaueren „Hinsehen“ festgestellt, dass es für diese Revision des Chips nicht zuständig ist und dies gemeldet. Um ein Laden dieses Moduls zukünftig zu verhindern kann man in die Datei /etc/modprobe.d/blacklist eine Zeile mit dem Inhalt blacklist 8139cp eintragen. Dann wird zukünftig das Laden des Moduls verhindert.
Abschließend noch ein weiteres Beispiel für eine USB-Webcam. Diese identifiziert sich als:
# lsusb -s 5:4 |
Versucht man nun, den Treiber für dieses Modul in der Datei modules.usbmap nachzuschlagen, erhält man keinen Treffer. Eine Suche beim Linux-USB-Project [7] verrät, dass für diese Logitech E3500 Webcam der uvcvideo-Treiber zu verwenden ist. Die modinfo-Ausgabe von uvcvideo sieht (auf die wichtigen Zeilen gekürzt) so aus:
# modinfo uvcvideo |
Die für das Beispiel interessante Zeile ist die allererste Alias-Zeile. Hier sind die Vendor- und Device-Angaben nicht relevant, wohl aber die Angaben ic (Interface Class), isc (Interface Subclass) und ip (Interface Protocol). Schaut man sich die USB-Details an, dann sieht man (wieder auf das Wesentliche gekürzt) Folgendes:
# lsusb -s 5:4 -v |
Hier wird der Treiber also über die Geräteklasse geladen. Die Kamera folgt dem „USB Video Class“ Standard. Somit kann der Treiber für diese Geräteklasse verwendet werden, auch wenn es keinen expliziten Eintrag für Vendor- und Device-IDs gibt. Andere Geräte, bei denen oft die Treiber über die Geräteklasse identifiziert werden, sind PCI-Bridges oder SATA-Controller im AHCI-Modus.
Schlussfolgerungen für die Praxis
Insgesamt kann man zu dem Thema Hardwarekompatibiltät für Linux folgende Schlussfolgerungen ziehen und weitere Hinweise geben:
- Alte Hardware läuft zwar im allgemeinen mit neuen Kerneln, neue aber nicht unbedingt mit alten Kerneln.
- Welche Hardware in Systemen und Peripheriegeräten verbaut ist, erfährt man oft leider nicht aus den Datenblättern. Hier sind am besten vor dem Kauf von Hardware einige Recherchen in den einschlägigen Foren und Kompatibilitätslisten sinnvoll.
- Open-Source-Treiber sind in jedem Fall gegenüber proprietären Treibern zu bevorzugen.
- Dank standardisiertern generischen Geräteklassentreibern sind bei den fundamentalen Komponenten eines PCs kaum Probleme zu erwarten.
- Die Schnittstellen zu Tastatur und Maus sind über ausgereifte Treiber nutzbar, im USB-Fall hilft ein USB-HID-Treiber (Human Interface Device).
- Die graphische Oberfläche kann im schlimmsten Fall mit dem VESA-Treiber genutzt werden, da alle modernen Graphikkarten auch die VESA-Modi unterstützen.
- Der Zugriff auf die Festplatte ist bei modernen Systemen oft über den AHCI-Klassentreiber möglich. Sollte das BIOS des Systems kein AHCI (Advanced Host Controller Interface) anbieten, dann hilft vielleicht ein „compatible“-Modus, in dem IDE-Platten emuliert werden. Dieser Modus ist allerdings sehr langsam, da er keine DMA-Unterstützung hat und man gegebenenfalls den ide_generic-Treiber bei der Installation laden muss.
- Ist das System erst einmal mit einer Basisinstallation boot- und lauffähig, kann man die eventuell noch fehlenden Treiber im Bedarfsfall hinzufügen. USB-Speichersticks werden eigentlich in fast allen Fällen problemlos unterstützt, um im Bedarfsfall größere Datenmengen zu einem Rechner ohne funktionierenden Netzwerktreiber zu übertragen.
- Selbst wenn bestimmte Treiber wie beispielsweise LAN- oder Audio-Treiber nicht im Kernel der Distribution enthalten sind, lassen sich diese oft beim Hersteller der Komponente als Quellcode herunterladen, der sich dann auch für ältere Kernel übersetzen lässt. So kann man auch auf etwas betagteren Distributionen neue Hardware zum Laufen bringen, bezahlt diesen Komfort aber mit der Verpflichtung, diese Treiber möglicherweise nach Kernel-Updates neu übersetzen zu müssen. Enterprise-Distributionen wie SUSE Linux Enterprise Server haben hier übrigens ein Treiber-Update-Modell, mit dem vorkompilierte Herstellertreiber für bestimmte Komponenten direkt bei Novell vom FTP-Server bezogen werden und auch nach Kernel-Updates weiterfunktionieren.
Ich habe in meiner langjährigen Berufspraxis eigentlich noch nie einen Fall erlebt, in dem ein System, das auf der gängigen PC-Architektur basierte, absolut nicht mit Linux laufen wollte. Damit bestätigt sich das eingangs erwähnte Zitat von Greg Kroah-Hartmann.
Links
Autoreninformation:
Rainer König arbeitet bei einem PC-Hersteller am Thema Linux-Hardware-Kompatibilität für PCs.
| < Zurück | Weiter > |
|---|