Inhaltsverzeichnis
Bewertung: 3
Die Kandidaten sollten in der Lage sein, interne und externe Geräte zu konfigurieren, dazu zählen insbesondere neue Festplatten, Terminalgeräte, seriell angeschlossene USVs, serielle Multiportkarten und LCD Bildschirme
Schlüsseldateien, Begriffe und Hilfsmittel beinhalten:
- XFree86
- modprobe
- lsmod
- lsdev
- lspci
- setserial
- usbview
- /proc/bus/usb
Die Installation neuer Hardware ist bereits in der LPI102 Prüfung Thema gewesen, allerdings ging es dort tatsächlich mehr um das grundsätzliche Verständnis von Hardwareressourcen wie IRQs, DMAs und IO-Adressen. Dieses Grundwissen setze ich also in diesem Fall voraus.
Grundsätzliches
Jedes Stück Hardware, das von Linux verwaltet bzw. benutzt werden soll benötigt einen Gerätetreiber. Ein Gerätetreiber ist unter Linux abstrakt gesehen einfach ein Stück des Kernelcodes, das entweder fest in den Kernel eingebunden ist, oder als Modul geladen werden kann.
Ursprünglich waren die ersten Versionen von Linux vollkommen statisch aufgebaut, was die Integration der Treiber anging. Jeder Treiber war fest in den Kernel integriert, aus der Sicht der Power-User war das ja kein Problem, man konnte (und kann) sich ja einen Kernel selbst zusammenstellen, der exakt auf die Bedürfnisse des jeweiligen Rechners angepasst ist. Mit dem Siegeszug von Linux kamen aber auch andere Zielgruppen ins Visier, die sicherlich davon abgeschreckt wären, wenn sie wegen jeder neuen Soundkarte einen neuen Kernel erstellen müssten.
Aus diesem Grund – und weil der Kernel einfach zu groß werden würde, wenn alle Treiber fest eingebaut wären – wurde das Prinzip der Kernelmoduke eingeführt. Kernelmodule sind also nichts weiter, als Teile des Kernels, die nicht grundsätzlich im Kernel integriert sind, sondern die bei Bedarf geladen werden können und auch jederzeit im laufenden Betrieb wieder „entladen“ werden dürfen, wenn sie nicht mehr gebraucht werden.
Bei der Erkennung angeschlossener Hardware spielt der Unterschied zwischen fest eingebauten Treibern und Modulen eine entscheidende Rolle. Während des Bootvorgangs überprüft der Kernel die Existenz aller Hardware, für die er einen fest eingebauten Treiber besitzt. Ein Gerät hingegen, das keinen fest eingebauten Treiber besitzt wird hier einfach übergangen (es sei denn, ein Programm greift auf dieses Gerät zu, was zum Laden des Moduls führen kann).
Module werden erst geladen, wenn sie gebraucht werden. Aus diesem Grund können natürlich auch Fehlermeldungen hinsichtlich verwendeter Hardware-Ressourcen erst auftreten, wenn das Modul geladen wird.
Bei der Installation neuer Hardware ist also immer die erste Frage, ob der Kernel bereits einen Treiber für diese Hardware eingebaut hat, oder ob wir ein entsprechendes Modul laden müssen. Ist der Treiber bereits eingebaut, so sollten wir nach dem nächsten Booten sofort Zugriff auf das Gerät bekommen, müssen wir aber erst ein Modul laden, so bekommen wir erst Zugriff bzw. auch erst die eventuellen Fehlermeldungen wenn das Modul geladen wird.
Die Hardware, die in diesem Prüfungsziel angesprochen ist, lässt sich in drei Kategorien einteilen:
- Festplatten
Ein Treiber ist für die jeweilige Anschlußtechnik notwendig (IDE, SCSI). Wenn bereits Festplatten dieser Anschlußtechnik installiert waren, benötigen wir keine Treiber. - Serielle Geräte
Ein Treiber ist für die serielle Schnittstelle nötig. Das serielle Gerät benötigt meist keinen Treiber, sondern ein Programm, das die Regeln der Kommunikation kennt. - LCD-Bildschirme
Der Treiber ist für die Graphikkarte notwendig, nicht für den Bildschirm selbst. Wird eine spezielle (digitale) Karte für LCD-Bildschirme benutzt, so muß sowohl der Kernel, als auch X11 einen entsprechenden Treiber benutzen. Die Unterstützung von 3D-Beschleunigern kann auch auf der Kernel-Ebene notwendig sein.
Wir werden hier zunächst einmal alle drei Kategorien durchsprechen und uns danach den angegebenen Befehlen widmen.
Installation der Geräte
Installation neuer Festplatten
Bei neuen Festplatten müssen wir natürlich zunächst wiederum unterscheiden, ob es zusätzliche Festplatten eines bestehenden IDE- oder SCSI Systems sind oder ob wir eine völlig neue Installation vornehmen, etwa Anschluß von SCSI-Geräten an ein bestehendes IDE-System.
Ein bestehendes System erweitern
Handelt es sich allein um die Aufrüstung eines bestehenden Systems, so benötigen wir keine Treiber. In diesem Fall ist es nur wichtig, die Namenskonventionen zu verstehen um die Platten auch ansprechen zu können.
Bei IDE-Festplatten ist die Namenskonvention sehr einfach. Jeder IDE-Bus kann zwei Platten aufnehmen. Eine davon ist als Master, die andere als Slave gejumpert. Wieviele IDE-Busse angeschlossen werden können, liegt an der Frage der Steckplätze und der freien Systemressourcen. Jeder IDE-Bus benötigt einen IRQ. Standardmäßig besitzen moderne Mainboards zwei Busse, denen die IRQs 14 und 15 zugeordnet sind.
Die Namen der einzelnen Platten setzen sich in alphabetischer Reihenfolge fort. Der Master des ersten Busses heißt /dev/hda, sein Slave folgt mit /dev/hdb. Im zweiten Bus wird das mit /dev/hdc (master) und /dev/hdd (slave) fortgesetzt. Entsprechend geht es weiter, der Master bekommt immer den ersten Buchstaben, der Slave den zweiten. Wir haben also eine ziemlich absolute Bezeichnungsart, aus deren Namen wir klare Rückschlüsse auf die Position der Platte ziehen können.
Bei SCSI sieht die Sache etwas anders aus. Die einzelnen Platten werden ebenfalls alphabetisch bezeichnet, statt den Buchstaben hd steht hier aber sd (SCSI-Disk). Die Namen sind also /dev/sda, /dev/sdb, …
Das Problem bei SCSI ist, dass diese Namensgebung keinerlei Rückschlüsse auf die Position der Platte zulässt. Ist nur ein Hostadapter installiert, so werden alle angeschlossenen Platten entsprechend ihrer SCSI-ID durchnummeriert. Die Platte mit der niedrigsten ID ist sda, die nächsthöhere ID wird sdb und so weiter.
Wenn aber zwei SCSI-Hostadapter im System installiert sind, so wird das einfach weitergezählt. Sind auf dem ersten Hostadapter etwa 3 Platten angeschlossen, (sda, sdb und sdc) so bekommt die erste Platte des zweiten Hostadapters den Namen /dev/sdd. Wird jetzt aber eine vierte Platte an den ersten Hostadapter angeschlossen, verschieben sich die Namen alle nach hinten. die erste Platte des zweiten Adapters ist jetzt also /dev/sde, die vierte des ersten Adapters bekommt /dev/sdd. Das kann dazu führen, dass das System nicht mehr richtig bootet, weil die Anweisungen in /etc/fstab, welche Partition wohin gemountet werden soll, jetzt völlig falsch sind.
Aus diesem Grund arbeiten viele Programme, die SCSI-Geräte direkt ansprechen nicht mit den Gerätedateien, sondern mit der direkten und absoluten Adressierung der Geräte nach dem Schema SCSI-Bus,SCSI-ID,LUN.
Bei der Neuinstallation von SCSI-Platten sollte also genau bedacht werden, ob sie eine Namensverschiebung zur Folge hat und welche Auswirkungen diese Verschiebung auf das System haben wird.
Die Frage, welcher Hostadapter der erste ist und welcher der zweite (…) erklärt sich über die Reihenfolge der geladenen Module. Auch das kann natürlich zu erheblichen Verwirrungen führen, weil ja z.B. auch ein am Parallelport angeschlossenes Zip-Laufwerk ein SCSI-Gerät ist. Wenn ein System also etwa einen echten SCSI-Hostadapter und ein solches Zip-Laufwerk besitzt, dann entscheidet die Frage, welches Modul zuerst geladen wird die Namenskonvention. Denn die erste Platte (/dev/sda) ist ja die erste Platte des ersten Hostadapters.
Wenn zwei baugleiche Adapter verwendet werden, dann wird nur einmal ein Modul geladen. In diesem Fall entscheidet sich die Frage nach erstem und zweitem Hostadapter an den IO-Adressen der beiden Geräte. Der Hostadapter mit der niedrigeren IO-Adresse ist der erste, der mit der höheren der zweite.
Neuinstallation eines Festplattenadapters
Soll ein völlig neues Festplatten-System installiert werden (etwa ein SCSI-Adapter in einem bisher reinen IDE-System), so gelten die normalen Regeln, die wir immer bei der Installation von Adapterkarten beachten müssen. Wir benötigen für Festplattencontroller (oder SCSI-Hostadapter) jeweils einen IRQ und womöglich auch einen DMA-Kanal. Außerdem müssen wir festlegen, welche IO-Adresse er nutzen soll. Bei modernen Anschlußtechniken sollte das alles kein Problem sein, weil Busse wie PCI die Vergabe dieser Ressourcen selbstständig vornehmen.
Wenn ein neues Gerät an den PCI-Bus angeschlossen wurde, dann kann mit Hilfe des Befehls
lspci
eine Liste der am PCI-Bus angeschlossenen Geräte dargestellt werden. Die Optionen -v und -vv erhöhen die Menge der Details, die ausgegeben werden. Dort sollten grundsätzlich die verwendeten IRQs und IO-Adressen zu finden sein, die für die Konfiguration der Module nötig sind. Der Befehl lspci scannt tatsächlich den PCI-Bus und gibt nicht nur die erkannten Geräte aus, sondern die tatsächlich vorhandenen.
Bei Systemen, die noch andere Geräte außer PCI benutzt ist diese Information oft nicht ausreichend, da auch hier z.B. IRQs verwendet werden, die aber in der PCI-Liste nicht auftauchen. Der Befehl
lsdev
gibt eine Liste aller Geräte (devices) aus, mit allen verwendeten IRQs, DMA-Kanälen und IO-Adressen. Alternativ dazu kann diese Information auch über /proc/interrupts, /proc/ioports und /proc/dma eingesehen werden. Der Befehl lsdev gibt aber alle diese Informationen zusammen in lesbarer Form auf die Standard-Ausgabe aus.
Jetzt sollte das Laden der entsprechenden Module kein Problem mehr sein, wenn darauf geachtet wurde die entsprechend richtigen Angaben in /etc/modules.conf (oder /etc/conf.modules auf älteren Systemen) gemacht wurden. Das wurde bereits im Kapitel 2.201.4 besprochen.
Installation serieller Geräte
Bei der Installation serieller Geräte müssen wir uns hauptsächlich um die Erkennung der seriellen Schnittstellen selbst kümmern. Mit Ausnahme der Terminalgeräte, die in /etc/inittab eingetragen sein müssen, kümmern sich meist spezielle Programme um die Ansteuerung der Geräte selbst.
Die seriellen Schnittstellen sind traditionell sehr wichtige Interfaces zum Unix-Rechner. Auf großen Installationen mit seriellen Terminals sind diese Schnittstellen sozusagen das Tor zum Rechner. Zur Ansteuerung der Schnittstellen selbst sind wiederum die entsprechenden Kerneltreiber nötig, die jedoch meist fest eingebaut sind. Eine Ausnahme dieses Prinzips stellen sogenannte Multiport-Karten dar, die viele serielle Schnittstellen mit nur einem IRQ ansteuern. Es existieren für praktisch alle dieser Multiport-Karten Treiber in Modulform für Linux. Entweder stellen die Hersteller selbst diese Treiber zur Verfügung, oder sie sind anderweitig in die Kernelentwicklung geflossen.
Multiport-Karten
Wie bereits erwähnt, sind serielle Schnittstellen für den Anschluß von Terminals von großer Bedeutung. Die klassischen seriellen Ports benötigen aber pro Port einen eigenen IRQ, was die maximale Menge der verwendbaren Schnittstellen erheblich einschränkt. Aus diesem Grund wirden sogenannte Multiport-Karten entwickelt, die als Multiplexer für serielle Ports arbeiten. Diese Karten arbeiten mit eigenen Prozessoren (tatsächlich gibt es solche Karten mit eigenem Intel 486 Prozessor), deren einzige Aufgabe darin besteht, viele serielle Ports mit nur einem IRQ zu betreiben. Auf dem Markt sind soche Karten mit bis zu 64 Ports pro IRQ.
Um solche Karten unter Linux anzusprechen sind die entsprechenden Kernelmodule zu laden. Der Standard-Kernel bietet bereits Treiber für die häufigsten dieser Karten an (Charakter-Devices/Non Standard Serial Ports), die nur noch als Modul compiliert werden müssen. Ist das entsprechende Modul geladen, so müssen wir die einzelnen Ports noch konfigurieren.
Die Konfiguration aller seriellen Schnittstellen läuft praktisch grundsätzlich über das Programm setserial. Dieses Programm arbeitet mit allen dem Kernel bekannten Schnittstellen und konfiguriert ihre Parameter (IO-Adresse, IRQ, UART-Typ). In den meisten Distributionen ist bereits ein Init-Script enthalten, das diese Aufgabe übernimmt und alle angeschlossenen Seriellen Schnittstellen konfiguriert. Entweder müssen hier entsprechende Zeilen durch Löschen des #-Zeichens aktiviert werden, oder es wird die Datei /etc/serial.conf benutzt, um die entsprechenden Einstellungen vorzunehmen.
Die Anwendung von setserial ist weiter unten noch genauer beschrieben.
Grundsätzliches zum Arbeiten mit seriellen Geräten
Alle seriellen Geräte, unerheblich, was sie eigentlich bewirken, benötigen zur Kommunikation mit dem Rechner mehrere sogenannte Kommunikationsparameter. Die vier entscheidenden Parameter sind
- Baudrate
Geschwindigkeit der Datenübertragung in Bit pro Sekunde. - Datenbits
Anzahl der Bits eines Bytes. Heute in der Regel 8, alte ASCII Übertragungen wurden aber auch mit 7 Datenbits vorgenommen. - Parität
Fehlerüberprüfung über eine Quersumme eines Bytes. Mögliche Werte sind even (gerade – wenn die Quersumme gerade ist, wird das Paritätsbit gesetzt), odd (ungerade – wenn die Quersumme ungerade ist, wird das Paritätsbit gesetzt), none (kein Paritätsbit wird verwendet), mark (das Paritätsbit ist immer gesetzt) oder space (das Paritätsbit ist nie gesetzt). - Stopbits
Anzahl der Stopbits – meist 1 oder 2.
Diese Parameter werden üblicherweise in der Form z.B. 9600 8N1 angegeben, was dann eben eine Geschwindigkeit von 9600 Bps, 8 Datenbits, keine Paritätsüberprüfung und ein Stopbit meint. Beide Kommunikationspartner müssen zwingend alle diese Parameter gleich eingestellt haben.
Die Einstellung dieser Parameter wird auf der Seite des externen Gerätes entweder über eigene Software (z.B. manche Terminals) oder über Hardwareschalter (Dip-Switches, Jumper) vorgenommen. Rechnerseitig werden diese Einstellungen über die Software vorgenommen, die die serielle Schnittstelle ansteuert, also z.B. das DFÜ-Programm (minicom) oder der Getty-Prozess (Terminal).
Terminal-Geräte
Sollen an einen Linux-Rechner serielle Terminals angeschlossen werden, so ist die erste Voraussetzung natürlich die Existenz entsprechend freier Schnittstellen. Sollten keine seriellen Schnittstellen mehr vorhanden sein (weil die beiden Standard-Schnittstellen etwa schon durch Maus und Modem belegt sind) ist eine Erweiterung durch Multiport-Karten denkbar, siehe letzten Abschnitt).
Serielle Terminals sind einfach nur Geräte, die aus einem Bildschirm und einer Tastatur bestehen. Vereinfacht gesagt wird alles, was auf die Tastatur des Terminals getippt wird, über die serielle Verbindung an den Rechner geleitet, während alles, was der Rechner auf die Schnittstelle schreibt, am Terminalbildschirm ausgegeben wird.
Damit ein solches Terminal funktioniert, müssen natürlich die oben genannten Kommunikationsparameter eingestellt sein. In der Regel arbeiten Terminals immer mit den Parametern 8N1, nur die Geschwindigkeit variiert.
Um schließlich dafür zu sorgen, dass auf dem Terminal auch ein Login-Prompt erscheint, muss ein getty-Prozess auf die entsprechende Leitung gelegt werden. Der Ort, wo das eingestellt wird ist die Datei /etc/inittab, die wir im Abschnitt 2.202.1 bereits besprochen hatten. Eine typische Zeile, um auf /dev/ttyS12 ein vt100 kompatibles Terminal in den Runleveln 2 bis 5 zu betreiben sähe folgendermaßen aus:
T0:2345:respawn:/sbin/getty -L ttyS12 9600 vt100
Die Einstellung der Geschwindigkeit wird hier über die 9600 erledigt. Das -L bedeutet eine lokale Anbindung ohne Erkennung eines Trägersignals (Carrier-Detect).
Es gibt hunderte von verschiedenen Terminals auf dem Markt, die sich alle unter anderem durch ihre Ansteuermechanismen unterscheiden. Darunter sind die Befehle zu verstehen, die z.B. die Cursorsteuerung oder das Löschen des Bildschirms erledigen. Linux (und alle anderen Unixe) haben aus diesem Grund eine Datenbank (terminfo), die die verschiedenen Steuerbefehle der Terminals kennen. Das in unserem Beispiel genannte VT100 Terminal stellt eine Art Quasi-Standard dar, der von vielen anderen Terminals übernommen wurde. Die Angabe des Terminaltyps, die in der Getty-Zeile gemacht wurde, wird als Umgebungsvariable TERM an die Login-Shell weitergegeben, so dass Linux dann weiß, wie das Terminal anzusteuern ist.
Wenn Terminals an serielle Leitungen angeschlossen werden, so sind noch weitere Einstellungen nötig bzw. möglich. Etwa die Frage, welche Tastenkombinationen bestimmte Steuerzeichen senden (Strg-C, Del, Backspace, …) oder ob Verzögerungen bei bestimmten Tasten verwendet werden sollen. Für die Einstellung dieser Eigenschaften wird das Programm stty verwendet.
Seriell angeschlossene USVs
USV steht für Unterbrechungsfreie Stromversorgung. Es handelt sich um Geräte, die beim Ausfall der Spannungsversorgung ohne Unterbrechung sofort weiter Energie an den Computer liefern. Es gibt verschiedene Techniken, die hier zur Verfügung stehen, vom kleinen Gerät, das dem Computer nur die Zeit gibt, sauber herunterzufahren, bis hin zu Geräten, die stundenlang Energie weiterliefern können. In allen Fällen benötigen diese Geräte eine Verbindung zum Computer, damit der weiß, dass er im Fall einer Spannungsunterbrechung jetzt auf Batteriestrom läuft.
In diesem Fall muß es möglich sein, dass der Computer entscheidet, was jeweils zu tun ist. In der Regel wird ein Rechner, der an eine USV angeschlossen ist, bei Stromausfall weiterlaufen, bis die USV ihm mitteilt, dass die Batterie langsam knapp wird oder der Netzstrom wieder da ist. Wenn die Batteriekapazität erschöpft ist, so muß der Rechner sauber runterfahren.
Die häufigste Methode, mit der eine USV einem Rechner mitteilen kann, ob sie gerade aktiv ist (der Rechner also auf Batteriestrom fährt) ist eine serielle Verbindung. Auch hier muß natürlich wieder festgelegt werden, mit welchen Kommunikationsparametern die Verbindung hergestellt werden soll. Auf der anderen Seite – der Seite des Rechners – muß ein Programm laufen, das die serielle Verbindung zur USV herstellt und überwacht. Dieses Programm kann dann die entsprechenden Schritte einleiten, die notwendig sind.
Ein typisches Programm, das diese Aufgabe übernimmt ist der UPS-Daemon upsd. UPS (Uninterrupted Power Supply) ist der englische Begriff für USV. Allerdings gibt es unterschiedlichste solcher Daemonen auf dem Markt, die sich zum Teil erheblich voneinander unterscheiden, was die Konfiguration angeht.
Entscheidend ist, dass Linux bereits bei der Konfiguration des init-Prozesses für den Fall vorgesorgt hat, dass der Strom ausfällt. In der Datei /etc/inittab, die wir im Abschnitt 2.202.1 bereits besprochen hatten, sind auch Befehle vorgesehen, die genau für diesen Zweck gedacht sind.
Der jeweils installierte Daemon-Prozess, der die USV steuert (z.B. upsd) gibt klar definierte Befehle an init weiter, wenn die Spannung abfällt oder wieder da ist. init kann dann entsprechend reagieren. In der Datei /etc/inittab können dazu die folgenden Befehl verwendet werden: powerwait Der genannte Befehl wird ausgeführt, wenn die Spannungsversorgung abfällt. Init wird darüber von einem Prozeß informiert, der mit der USV verbunden ist. Init wartet, bis der Prozess abgearbeitet ist (wait). powerfail Wie Powerwait, nur wartet init nicht auf die Abarbeitung, sondern fährt gleich fort. powerokwait Der Prozess, der abgearbeitet wird, sobald init darüber informiert ist, dass die Spannung wieder da ist. powerfailnow Dieser Prozess wird abgearbeitet, wenn init gemeldet bekommt, dass die Batterie der USV so gut wie leer ist und die Spannung trotzdem noch nicht wieder da ist.
Beispiele für die Anwendung können der früher schon besprochenen Darstellung der inittab-Einstellungen entnommen werden.
Installation von LCD-Bildschirmen
Die Verwendung von LCD-Flachbildschirmen ist in der Regel kein großes Problem, die einzige Umstellung betrifft nur die graphische Oberfläche X11. Im Textmodus sind diese Bildschirme völlig kompatibel zu den normalen VGA-Modi, können also sofort benutzt werden. Nur die Konfiguration von X11 muß etwas anders angegangen werden. Dort werden ja normalerweise die genauen Ansteuersequenzen der Röhrenbildschirme genutzt, um den Bildschirm-Modus einzustellen. Ein LCD-Monitor arbeitet aber mit völlig anderen Mechanismen, von daher sind hier ein paar Dinge notwendig.
Die üblichen Konfigurationsprogramme für X11 (XF86Setup, Sax2, dexconf,…) enthalten bereits die Unterstützung für diese Bildschirme, es sollte also kein Problem sein, sie anzusteuern.
Etwas anders sieht es aus, wenn es um digital angesteuerte Bildschirme geht. Hier ist nicht die Steuerung des Bildschirms das Problem, sondern die Konfiguration der Graphikkarte. Digitale Graphikkarten für LCD-Monitore werden z.T. den üblichen Standards keineswegs entsprechen, aus diesem Grund ist es nicht möglich, diese Karten ohne speziellen Treiber anzusprechen. Immerhin bieten inzwischen viele Abbieter solcher Graphikkarten auch Treiber für Linux an.
Die entsprechenden Einstellungen sind alle in der Datei XF86Config vorzunehmen. Für die X11-Versionen bis 3.3 liegt diese Datei in /etc oder /etc/X11. Neuere Versionen ab 4.0 suchen die Konfigurationsdatei unter /etc/X11/XF86Config-4
Die wichtigen Sektionen sind hier die Sektionen Monitor, Modes und Device. Die entsprechenden Werte müssen aus dem Handbuch des jeweiligen Monitors entnommen werden.
Die verwendeten Hilfsmittel
Hier nochmal ein Überblick über die in diesem Kapitel benutzten Programme und ihre Anwendung.
modprobe
Wir haben schon im Abschnitt 2.201.4 die Anwendung von modprobe und insmod kennengelernt. Dem ist an dieser Stelle nichts mehr hinzuzufügen.
lsmod
lsmod ist der Befehl, der die augenblicklich geladenen Module anzeigt. Er kennt keinerlei Optionsschalter und ist daher sehr einfach zu bedienen. Die Darstellung schließt auch ein, welches Modul von welchen anderen Modulen benötigt wird.
lsdev
Auch dieser Befehl kennt keinerlei Optionsschalter. Er wird benutzt, um Informationen über Systemressourcen wie IRQs, IO-Ports und DMA-Kanäle auszugeben. Er gibt so einen schnellen Überblick, welche dieser Ressourcen von welcher Hardware bzw. von welchem Treiber benutzt wird.
lspci
lspci ist ein Programm, das Informationen über alle PCI-Busse des Systems und die daran angeschlossenen Geräte zeigt. Wenn hier von allen PCI-Bussen die Rede ist, so ist damit in der Regel der PCI-Bus und der AGB-Steckplatz gemeint, der ja technisch gesehen nichts anderes als ein eigenständiger PCI-Bus mit nur einem Steckplatz ist.
lspci scannt den PCI-Bus und ermittelt anhand einer systemweiten Datenbank (/usr/share/misc/pci.ids) die dazu passenden Informationen über Hersteller und Art des angeschlossenen Gerätes.
Über die Optionsschalter -v und -vv kann die Ausgiebigkeit der Informationen erhöht werden.
setserial
setserial ist das Programm, mit dem wir die Konfiguration einer seriellen Schnittstelle vornehmen. Dieses Programm kennt verschiedendste Parameter, von denen hier nur die gebräuchlichsten dargestellt werden sollen.
Jede serielle Schnittstelle benutzt einen Baustein, der UART (Universal Asynchronus Receiver Transmiter) genannt wird. Die gebräuchlichsten dieser Bausteine sind 16450 und 16550A. Die Handbuchseite von setserial listet alle unterstützten UARTs auf.
Neben der Information, welcher UART benutzt wird, sollten mindestens noch die Informationen der IRQs und IO-Adressen bei der Konfiguration verwendet werden. Ein üblicher Befehl um eine serielle Schnittstelle zu konfigurieren ist also
setserial Gerätedatei uart Baustein port IO-Adresse irq IRQ
Ein typisches Beispiel für die Standard-Schnittstellen eines PC wäre also:
setserial /dev/ttyS0 uart 16550A port 0x3F8 irq 4 setserial /dev/ttyS1 uart 16550A port 0x2F8 irq 3
In vielen Fällen ist setserial auch in der Lage, automatisch zu erkennen, welche IRQs und Ports benutzt werden. In diesem Fall kann der folgende Befehl benutzt werden:
setserial Gerätedatei auto_irq autoconfig
Jetzt versucht setserial selbst herauszufinden, welcher UART, IRQ und IO-Port benutzt wird. Es ist aber nicht in allen Fällen möglich, das fehlerfrei herauszubringen, im Zweifelsfall ist die manuelle Konfiguration also vorzuziehen.
stty
Das Programm stty dient dazu, Terminal-Einstellungen (insbesondere für serielle Terminals) anzuzeigen und zu ändern. Die komplette Darstellung der möglichen Parameter würde sowohl den Rahmen dieser Dokumentation sprengen, als auch unnötig für die LPI-Vorbereitung sein. Wichtig ist aber, zu wissen, dass mit dem Befehl
stty -a
die Einstellungen des aktuellen Terminals angezeigt werden können. Sollen hingegen die Einstellungen einer beliebigen seriellen Leitung angezeigt werden, so wird das zu untersuchende Gerät mit der Option -F (oder –file=) angegeben.
stty -F /dev/ttyS1 -a
zeigt also alle Einstellungen der Schnittstelle /dev/ttyS1 an.
usbview
usbview ist eine graphische (gdk-basierte) Anwendung, die alle an den USB-Hubs angeschlossenen Geräte darstellt und deren Eigenschaften zeigt.
/proc/bus/usb
Hier ist die Wurzel der USB-Informationen, die der Kernel über das /proc-Dateisystem anbietet. Im Verzeichnis devices sollten Informationen über alle angeschlossenen USB-Geräte gefunden werden.