Kartenspiele

Wie schon im Artikel ‘Wie laufen sie denn?’ [1] zu lesen war, stellt die Installation von Linux-Notebooks keine unüberwindliche Hürde dar. Auch in der Leistungsfähigkeit stehen diese Geräte heute ihren Kollegen vom Desktop kaum noch nach. Linux unterstützt inzwischen ausgefeiltes Powermanagement und ermöglicht auch abseits der Stromnetzversorgung mehrstündigen Betrieb. Einer der markantesten Unterschiede zwischen Notebooks und ortsfesten Geräten dürfte der PCMCIA-Bus sein.

Frühe Laptops verfügten aufgrund ihrer Größe noch über ein bis zwei normale ISA-Slots. Neben der fortschreitenden Verkleinerung der Systeme zwang die Energieversorgung zum Umdenken - übersteigt doch der Strombedarf von Standard-PC-Erweiterungskarten bei weitem das, was ein Notebook-Akku über einen glaubwürdigen Zeitraum leisten kann. Es kam zur Entwicklung der PCMCIA-Karten - heute als PC Card bezeichnet. Bei den Anforderungen an diese Geräte stehen Miniaturisierung und Minimierung des Energieverbrauchs im Vordergrund. In puncto Stromverbrauch müssen sie eng mit dem Powermanagement des mobilen Rechners zusammenarbeiten, um lange Akkulaufzeiten zu ermöglichen.

Eine besondere Herausforderung stellt die Handhabung der Karten dar. Kann man bei Desktops noch davon ausgehen, dass nur technisch qualifizierte Personen Steckkarten wechseln, erfolgt der Austausch der PCMCIA-Karten durch den normalen Anwender. Viele der kleinen Erweiterungskarten sind daher Hot-Plug-fähig und lassen sich im laufenden Betrieb einstecken beziehungsweise herausnehmen - eine Fähigkeit, die sonst allenfalls in teuren Serversystemen zur Erhöhung der Verfügbarkeit zum Einsatz kommt.

Komplexe Strukturen zur Identifikation

Ähnlich wie bei PCI-Karten bringen PC Cards einen Mechanismus zur Beschreibung der Karte mit. Diese Identifikation heißt Card Identification Structure (CIS). Der Identifikationsblock beschreibt den Hersteller und die Karte. Weiter gehören dazu eine ID, mögliche Interrupts und Speicheradressbereiche sowie allgemein die Funktionsklasse der Karte. Mögliche Funktionsklassen sind: Multifunktion, Memory, Serial, Parallel, Fixed Disk, Video, Netzwerk und AIMS (Auto-Increment Mass Storage).

Im Linux PCMCIA Programmer’s Manual kommt der CIS-Mechanismus wegen seiner programmiertechnischen Komplexität nicht besonders gut weg. So sind die Informationen, mit denen sich die Karten identifizieren lassen, in einer Kette von Tupeln mit unterschiedlicher Struktur kodiert. Jede definierte Eigenschaft einer PC Card besteht aus einer Kennung, der Länge des entsprechenden Datenblocks und dem Datenblock selbst. Das Auslesen dieser Daten kann nur über aufwändige Parser-Läufe erfolgen. Dem geneigten Leser sei hier ein Blick in den Linux PCMCIA Programmer’s Guide, Seiten36 bis 40, empfohlen (siehe Kasten ‘Quellen’). Zum Glück verbirgt die Software die innere Komplexität vor dem Benutzer vollständig.

In Linux fußt die Unterstützung von PCMCIA-Karten auf drei Komponenten: einem Kerneltreiber für den PCMCIA-Bus, jeweils einem für die PCMCIA-Karten sowie dem Daemon cardmgr für die Kontrolle des Kartenwechsels und der Module. Letzterer läuft als User-Level-Prozess und steuert auf Basis einer Konfigurationsdatei, meist /etc/pcmcia/config, das dynamische Einbinden und Herausnehmen von Treibern und Karten.

In Linux 2.2.x und weitgehend auch 2.3.x wird das PCMCIA-Paket noch separat geliefert und weiterentwickelt. Die PCMCIA-Treiber sind ausschließlich in Form von Kernelmodulen implementiert, die der Benutzer nachträglich installieren muss. Erst mit den letzten 2.3-Kernelversionen hielt die PCMCIA-Unterstützung als fester Bestandteil Einzug in die Kernelquellen. Hier muss man lediglich noch die PCMCIA-Unterstützung in der Kernelkonfiguration aktivieren. Leider geriet dies unübersichtlicher als unter 2.2, da sich die Aktivierung der Module für die Erweiterungskarten in den jeweiligen Untermenüs versteckt. Dafür entfällt aber das zusätzliche Übersetzen und Installieren des PCMCIA-Paketes. Lediglich die Tools und gegebenenfalls Treiber, die nicht Bestandteil der Kernelquellen sind, muss der Benutzer noch zusätzlich einspielen. Informationen, wo diese zu finden sind, liefert der Kasten ‘Quellen’.

Auch der 2.4er-Kernel realisiert die Treiber nach wie vor als Module, sodass sie sich per Hot-Plug bei Bedarf nachladen und wieder entfernen lassen. Zwar vermitteln die aktuellen Testversionen des 2.4-Kernels bereits einen stabilen Eindruck, aber sie unterliegen noch häufigen Änderungen. Für diejenigen, die getreu dem Motto ‘Never change a running system’ lieber auf ein stabiles System setzen, folgt daher ein Überblick über die erforderlichen Handgriffe, um PCMCIA-Karten unter Linux 2.2 zum Laufen zu bringen.

Am Anfang stehen die Quellen

Zuerst ist das Paket für die PCMCIA-Unterstützung zu installieren. Bei dem für die Tests in diesem Artikel benutzten SuSE-6.4 steht ein entsprechendes Paket zur Verfügung. Andere Distributionen verfügen meist ebenfalls über vorgefertigte Softwarearchive. Weiterhin muss der Kernel Unterstützung für das Powermanagement (APM) bieten, da sonst das dynamische Nachladen der PCMCIA-Treiber aufgrund fehlender Symbole scheitert. Für den Einsatz spezieller Karten muss man die PCMCIA-Quellen installieren und übersetzen, die Kernelquellen sind ebenfalls unabdingbar. Nach dem Einspielen des entsprechenden RPM-Pakets über yast liegen diese in /usr/src/packages/SOURCES/pcmcia-cs-3.1.11.tar.gz vor. Ein make config im obersten Verzeichnis der ausgepackten *.tar.gz-Datei konfiguriert das PCMCIA-Subsystem. Der Kasten ‘PCMCIA-Parameter für Linux 2.2.14’ zeigt Details am Beispiel der Kernelversion 2.2.14.

Das PCMCIA-Paket nimmt keine Änderungen am Linux-Kernel vor. Prinzipiell muss man daher nicht den gesamten Kernel neu übersetzen, da er alle PCMCIA-Komponenten als Module einbindet. Zur Aktivierung der PCMCIA-Unterstützung muss der Administrator in /etc/rc.config noch einige Parameter setzen. Dies geschieht bei SuSE automatisch bei der Installation des PCMCIA-Pakets. Die Variable START_PCMCIA steuert die Unterstützung insgesamt. Nur wenn sie den Wert ‘yes’ hat, aktiviert der Kernel den PCMCIA-Support beim Systemstart. Die folgenden Variablen konfigurieren die PCMCIA-Basismodule.

PCMCIA muss mit dem Namen des PCMCIA-Chipsatzes initialisiert werden. Hier stehen die Module i82365 und tcic zur Auswahl. PCMCIA_PCIC_OPTS konfiguriert Parameter, die beim Laden des Chipsatzmoduls übergeben werden sollen, zum Beispiel eine Liste freier Interrupts. Dies ist zu empfehlen, wenn es zu Konflikten kommen sollte. PCMCIA_CORE_OPTS steuert entsprechend die Optionen beim Laden des Modules pcmcia_core.

Vorsicht bei gemischten Versionen

SuSE startet die PCMCIA-Unterstützung über ein rc-Skript. Dieses lädt die Module für den PCMCIA-Chipsatz sowie das pcmcia_core-Modul und startet den cardmgr, der den PCMCIA-Bus überwacht. Sobald der Benutzer eine Karte einschiebt oder herausnimmt, lädt respektive entfernt cardmgr die erforderlichen Kartenmodule. Dazu liest er beim Einstecken die Herstellerinformationen aus und ermittelt anhand der Konfigurationsdateien in /etc/pcmcia/ das entsprechende Modul.

Damit der cardmgr etwa beim Einsetzen einer Netzwerkkarte automatisch das Netz konfiguriert, muss in der Datei /var/state/pcmcia/schema die Zeile ‘SuSE’ stehen. Der Pfad dieser Datei variiert zwischen den PCMCIA-Versionen. Bei unseren Tests funktionierte nach einem Update cardinfo nicht mehr korrekt. Ursache war hier ein geänderter Pfad, unter dem das Programm die Dateien schema und stab sucht. In der Folge konnte cardinfo Kartenstatus und Herstellerinformationen nicht mehr anzeigen, und die IP-Konfiguration erfolgte nicht mehr automatisch nach Einsetzen einer Karte. Ein Link von /var/lib/pcmica auf den bestehenden Pfad /var/state/pcmcia wirkt hier Wunder. Ähnliches gilt, wenn cardinfo die Warnung ‘wrong Version’ ausgibt. Ursache ist ein Versionenmix, das heißt, beim Update der PCMCIA-Treiber sollte man tunlichst die passenden Tools gleich mit aufspielen.

Ähnlich wie unter Windows meldet unter Linux der cardmgr das Einsetzen, Einbinden und Herausnehmen von Karten akustisch. Beim erfolgreichen Einsetzen einer Karte erfolgen zwei kurze hohe ‘Beeps’. Findet er den richtigen Treiber nicht, kann ihn nicht laden oder ist die entsprechende Konfiguration fehlerhaft, so wird dies mit einem tiefen längeren ‘Beep’ angezeigt.

Tools zur Fehlersuche

Natürlich wäre Linux nicht Linux, wenn es im letzten Falle nicht entsprechende Werkzeuge und Kniffe gäbe, die es dem Benutzer ermöglichen, dem Problem auf die Spur zu kommen und sich selbst zu helfen. Wie Abbildung 1 zeigt, existiert ein grafisches Panel, cardinfo, das den Zustand der PCMCIA-Slots anzeigt und dem Nutzer das geregelte Herausnehmen von Karten erlaubt, die kein Hot-Plug unterstützen. Über die Kontextmenüs der Buttons ‘Socket 0’ beziehungsweise ‘Socket 1’ lassen sich Aktionen wie eject, suspend und reset auslösen.

Wer unter Linux die Kommandozeile bevorzugt, kann für vergleichbare Funktionen das Programm cardctl oder die Systemdateien unter /proc/bus/pccard verwenden. cardctl bietet im Prinzip dieselben Informationen wie cardinfo. cardctl status liefert die Low-Level-Informationen wie die Kartenspannung in Volt. cardctl ident gibt die wichtigsten Informationen aus der schon oben angesprochenen Karteninformationsstruktur CIS aus. Dies sind Hersteller und Bezeichnung der Karte, die so genannte Manufacturer ID und die Funktionsklasse der Karte, wie die folgende Ausgabe zeigt:

Socket 0:
  product info: "3Com Corporation",
 "3C562C/3C563C", "EtherLink III", "LAN+Modem PC Card"
  manfid: 0x0101, 0x0562
  function: 6 (network)
Socket 1:
  product info: "NIKON", "Card Camera", "COOLPIX E100 Ver 1.1 "
  function: 4 (fixed disk)

Dieselben Informationen finden sich in den Special-Files unter /proc/bus/pccard. Sie sind hilfreich, wenn man selbst der einen oder anderen nicht direkt unterstützten Karte auf die Sprünge helfen will. In der PCMCIA-Konfigurationsdatei beschreiben ‘device’-Einträge die Einstellungen der Treiber. Diese werden in den kartenspezifischen ‘card’-Abschnitten referenziert. Listing 1 zeigt ein Beispiel mit der Definition des Nokia-CardPhone-Treibers und der entsprechenden Karte. Die Nokia-Karte wird über den Kartennamen und die Manfacturer-ID identifiziert. Etwas flexibler erfolgt dies mit dem ‘version’-Statement und dem ‘*’-Platzhalter, wie im Xircom-Eintrag zu sehen. Dieser beschreibt eine Multifunktionskarte, für die der Kernel sowohl den Tulip-Ethernet-Treiber als auch den seriellen Treiber benutzt.

#

# Device driver definitions

#

device "nokia_cs"
  class "serial" module "nokia_cs"
...
#
# Adapter definitions
#
card "Xircom CBEM56G-100 CardBus 10/100 Ethernet + 56K Modem"
  version "Xircom", "*", "CBEM56G"
  bind "tulip_cb" to 0, "serial_cb" to 1

card "Nokia Mobile Phones"
  manfid 0x124, 0x800
  bind "nokia_cs"

Will man unter Linux eine Karte verwenden, die nicht direkt unterstützt wird, sieht es unter Umständen gar nicht so schlecht aus. Handelt es sich um ein Gerät, für das wahrscheinlich ein entsprechender Treiber existiert - zum Beispiel ein Modem oder eine Netzwerkkarte -, kann folgendes Vorgehen zum Erfolg führen:

Ein Lösungsansatz: Versuch und Irrtum

Zunächst per cardctl ident die Kennung der Karte ermitteln. Als Nächstes in der Konfigurationsdatei einen vergleichbaren Eintrag suchen, kopieren und entsprechend anpassen. Dann bekommt der Cardmanager via kill -HUP ‘cat /var/run/cardmgr.pid’ oder killall -HUP cardmgr das Signal, seine neue Konfiguration einzulesen, und mit ein wenig Glück funktioniert die Karte.

Je nach Gerätetyp lädt Linux anschließend weitere, gerätespezifische Konfigurationsdateien nach. Zum Beispiel konfiguriert /etc/pcmcia/network automatisch das Interface der eingesetzten Netzwerkkarte. Analoge Konfigurationsskripte existieren unter anderem für serielle und parallele Geräte, SCSI- oder ISDN-Karten. Über entsprechende Tools lassen sich Systemparameter wie Interrupts und gerätespezifische Optionen einstellen. So kann das System bei einer SCSI-Karte per mount die am SCSI-Bus angeschlossenen Laufwerke bereitstellen beziehungsweise beim Auswerfen der Karte via umount wieder entfernen.

Beim 2.2er Linux Kernel ist das Booten von PCMCIA-Geräten nicht ganz einfach. Da die Basistreiber nur als Module vorliegen und der cardmgr als User-Level-Dämon läuft, ist ein direktes Booten von einem PCMCIA-Gerät, zum Beispiel einem CD-ROM-Laufwerk mit bootbarer CD, nicht möglich. Diese Einschränkung lässt sich über die Erstellung einer Initial Ramdisk per mkinitrd umgehen, wenn das Notebook über ein anderes bootfähiges Gerät wie Festplatte oder Floppy verfügt. Dabei wird von dort ein Minimalsystem gestartet, das die Treiber und Dämonen startet und dann das eigentliche /-Dateisystem auf dem PCMCIA-Gerät per Remount bereitstellt.

Unter Linux kann die Wahl der richtigen Karte schwierig werden. Selbst die Hardware Compatibility List und das PCMCIA-HowTo sind keine Garantie dafür, dass eine Karte in jedem Notebook funktioniert. Wir wollten vor allem wissen, mit welchen Problemen in der Praxis zu rechnen ist. Dazu haben wir eine Auswahl getroffen, die einen Querschnitt durch das Angebot von PCMCIA-Erweiterungen darstellt. Dabei stehen sich bewusst auch alte und neue Modelle gegenüber. Dennoch deckt der Artikel bei weitem nicht das ganze Spektrum verfügbarer Karten ab. Eine Reihe von Produkten taucht hier nicht auf, obwohl Linux sie unterstützt.

In medias res: Die Karten gelegt

Einige Hersteller, wie Nokia, bieten sogar Linux-Treiber im Web an. Leider stammt der Nokia-eigene Treiber aus dem Jahre 1998 und wurde anscheinend noch nie ohne Debug-Option übersetzt. So muss zum Kompilieren vor dem ersten #ifdef PCMCIA_DEBUG die Variable PCMCIA_DEBUG definiert werden. Dies kann beispielsweise durch Einfügen der Zeile #define PCMCIA_DEBUG 5 nach den include-Anweisungen in der Datei nokia_cs.c erfolgen.

Andere, zum Beispiel Elsa, verweisen auf frei verfügbare Linux-Treiber oder stellen interessierten Entwicklern die erforderliche Dokumentation zur Verfügung. Für eine angenehme Überraschung sorgte Lucent: Dem Wavelan-Starterpaket liegt eine CD bei, die unter anderem Linux-Treiber nebst einer Installationsanleitung enthält.

Multifunktionskarten mit Tücken

Besonders hakelig zeigen sich Multifunktionskarten - nicht nur unter Linux. So existiert für das aktuelle Xircom-Modell RealPort II kein Support für das ISDN-Modul; bei der D-Link-Karte war das Modem nicht zur Mitarbeit zu überreden. Darüber hinaus können Multifunktionskarten bei älteren Notebooks für Probleme mit Shared Interrupts sorgen. In solchen Fällen muss man unter Umständen zur Nutzung einer Funktion die andere(n) deaktivieren, da man die störende Karte nicht herausnehmen kann. Diese Klippe umschifft Xircom mit der RealPort II geschickt, da es sich tatsächlich um getrennte Karten handelt, die sich auch einzeln einsetzen lassen (siehe Abbildung 2). Lediglich die Bauart mit den vergleichsweise robusten Steckverbindungen lässt sie nach außen hin wie eine einzige Karte erscheinen. In Einzelfällen kollidiert die serielle Schnittstelle mit dem in vielen Notebooks vorhandenen IR-Port. Hier kann es helfen, den IR-Port im BIOS zu deaktivieren oder auf eine andere Schnittstelle zu legen.

Eine weitere Schwierigkeit liegt in der Kombination von LAN-Schnittstelle und Modem in einer Karte. Wählt man sich unterwegs in das Netz ein, das der Rechner normalerweise über den LAN-Port erreicht, muss der Benutzer die Routen von der LAN-Karte entfernen oder das Netz-Device per ifconfig eth0 down deaktivieren, damit die Pakete korrekt über die Modem-Schnittstelle geroutet werden.

Abhilfe für diese Probleme verspricht die Verwendung von Schemata. So kann der Anwender dem PCMCIA-Subsystem entweder per cardctl schema <name> oder über den Boot-Parameter schema <name> (LiLo) eine Kennung der jeweiligen Konfiguration übergeben. Dies erlaubt die Einstellung auf unterschiedliche Umgebungen. Nachteil dabei: Der Nutzer muss die gewünschte Konfiguration auswählen. Geht es um unterschiedliche Netzumgebungen, kann das Utility divine helfen. Es lässt sich über /etc/divine.conf so konfigurieren, dass es verschiedene Netzumgebungen an charakteristischen Rechnern erkennt, zum Beispiel Name- oder Fileservern. Listing 2 zeigt ein Beispiel. Dazu schickt es Arp-Pakete an diese Rechner. Je nach aktuell verfügbarem Netz antworten einige der konfigurierten Systeme, und divine kann das Netz automatisch konfigurieren - dies kann Nameserver, HTTP-Proxy inklusive Port, Default-Gateway und ein beliebiges Shell-Skript umfassen. Zusätzlich besitzt jede Konfiguration einen Namen, den divine ausgibt, wenn es die jeweilige Konfiguration erkennt.

# Lines starting with hash are comments.
# 
IP/netmask:ip[|ip...]:default_gw:resolv.conf:proxy:port:shell-script:description
10.0.0.2/24:10.0.0.1|10.0.0.3:10.0.0.1:resolv.conf.default:10.0.0.1:3128::Home
160.45.45.167/23:160.45.44.1:160.45.44.1:resolv.conf.mathe:http-proxy.fu-berlin.de:80::Uni

Fazit

Die Hersteller nehmen Linux-Benutzer zunehmend, aber noch schleppend als Zielgruppe wahr. So bieten SMC, Nokia und Lucent bereits eigene Treiber für ihre Produkte an. Die meisten geben immerhin Hinweise auf Quellen, über die Treiber bezogen werden können, wenn diese nicht ohnehin im Kernel enthalten sind.

Dennoch gilt: Das Neueste ist nicht unbedingt das Beste - unter Linux eigentlich keine neue Weisheit. Bei Notebooks trifft sie umso mehr zu, als die Hardware trotz aller Bemühungen noch nicht so gut standardisiert ist wie bei Desktop-PCs oder Servern. Wer auf Nummer Sicher gehen will, tut gut daran, vor der Anschaffung einer Karte mindestens in die HowTos zu schauen, besser noch die Karte vorab zu testen. Verwendet man jedoch gängige unterstützte Karten, dann gestaltet sich die Nutzung von PC Cards in Linux-Notebooks recht einfach.

Ulrich Jörgens
arbeitet bei der Materna GmbH als Berater für Systemmanagement.

Michael Kuschke
ist technischer Produktmanager im Bereich PC-Management der Materna GmbH, Dortmund.

Literatur

[1] Ulrich Jörgens, Michael Kuschke; Linux mobil; Wie laufen sie denn?; Besonderheiten beim Einrichten von Linux auf Notebooks; iX 7/1999, S. 56 ff.

[2] Anna Kobylinska, Filipe Martins; PowerBook-Linux; Äpfel auf Reisen; LinuxPPC 1999 Q3 und Yellow Dog Linux 1.1; iX 1/2000, S. 74 ff.

(avr)