PCMCIA mit Kernel 2.4.4
Heute hier mal eine interessante Erkenntnis: Lange habe ich versucht, den PCMCIA-Krempel meiner SuSE 7.2 zum Laufen zu kriegen. Mit dem SuSE-Original Kernel und den beigepackten Modulen geht's, mit dem selbst übersetzten Kernel: Fehlanzeige! Das Modul i82365 kann nicht geladen werden: Intel PCIC-Probe: not found Irgenwann fiel mir auf, dass meine PCMCIA-Version (dmesg) nicht mit der übereinstimmt, die man beim booten des SuSE-Kernels zu sehen bekommt. Außerdem war in der Konfiguration des SuSE- Kernels gar kein PCMCIA eingebaut! Des Rätsels Lösung: SuSE verwendet das externe PCMCIA-Package (Sourcen auf der DVD / den CDs). Wenn man diese installiert und sich das README-2.4 durchliest, sieht man warum es mit eingebautem PCMCIA so gar nicht gehen kann: statt des Moduls 'i82365' verwende man für Kernel-basiertes PCMCIA doch bitte das Modul 'yenta_socket' Gesagt - getan ... und schon klappts auch so. Man muß also nur statt des einen das andere Modul laden. Die Anpassung im Start- skript '/etc/init.d/pcmcia' ist allerdings nicht so offensichtlich. Da wird mit '/sbin/probe -m' der Controller-Typ ausgelesen und in die Variable PCMCIA gesetzt. und genau dieses Modul wird dann per 'modprobe' geladen. Man kann also ein PCMCIA=yenta_socket hinter die Abfrage '/sbin/probe -m' setzen und alles läuft bestens. Ich habe allerdings in /etc/rc.config einfach noch ein PCMCIA_YENTA_SOCKET=yes eingefügt und eine Abfrage ins Startskript eingebaut, die den Wert von PCMCIA auf yenta_socket setzt, falls er vorher i82365 war und PCMCIA_YENTA_SOCKET auf 'yes' steht. Noch eleganter wäre vielleicht der Versuch, bei fehlgeschlagenem Laden des i82365-Moduls einfach probehalber das Yenta- Modul zu laden. Naja, vielleicht hilft dieser Hinweis ja irgendwem. Gruß Andreas
Am Mit, 12 Sep 2001, schrieb Andreas Kretzer:
Heute hier mal eine interessante Erkenntnis:
Lange habe ich versucht, den PCMCIA-Krempel meiner SuSE 7.2 zum Laufen zu kriegen. Mit dem SuSE-Original Kernel und den beigepackten Modulen geht's, mit dem selbst übersetzten Kernel: Fehlanzeige!
Das Modul i82365 kann nicht geladen werden: Intel PCIC-Probe: not found Irgenwann fiel mir auf, dass meine PCMCIA-Version (dmesg) nicht mit der übereinstimmt, die man beim booten des SuSE-Kernels zu sehen bekommt. Außerdem war in der Konfiguration des SuSE- Kernels gar kein PCMCIA eingebaut!
Des Rätsels Lösung: SuSE verwendet das externe PCMCIA-Package (Sourcen auf der DVD / den CDs). Wenn man diese installiert und sich das README-2.4 durchliest, sieht man warum es mit eingebautem PCMCIA so gar nicht gehen kann:
statt des Moduls 'i82365' verwende man für Kernel-basiertes PCMCIA doch bitte das Modul 'yenta_socket'
Ging schon öfter über die Liste Wichtig ist auch, daß man in dem selbstgebackenen Kernel den Ganzen PCMCIA-Krempel als Modul übersetzt und nicht fest in den Kernel einkompiliert, sonst liefert das Startskript Fehlermeldungen.
Gesagt - getan ... und schon klappts auch so. Man muß also nur statt des einen das andere Modul laden. Die Anpassung im Start- skript '/etc/init.d/pcmcia' ist allerdings nicht so offensichtlich. Da wird mit '/sbin/probe -m' der Controller-Typ ausgelesen und in die Variable PCMCIA gesetzt. und genau dieses Modul wird dann per 'modprobe' geladen. Man kann also ein
PCMCIA=yenta_socket
hinter die Abfrage '/sbin/probe -m' setzen und alles läuft bestens. Ich habe allerdings in /etc/rc.config einfach noch ein PCMCIA_YENTA_SOCKET=yes eingefügt und eine Abfrage ins Startskript eingebaut, die den Wert von PCMCIA auf yenta_socket setzt, falls er vorher i82365 war und PCMCIA_YENTA_SOCKET auf 'yes' steht.
Noch eleganter wäre vielleicht der Versuch, bei fehlgeschlagenem Laden des i82365-Moduls einfach probehalber das Yenta- Modul zu laden.
Die Variable PCMCIA wird ja in /etc/rc.config gesetzt. Dort habe ich um die Definition eine if-Schleife gebaut, die über uname -r die Kernelversion abfragt und dann PCMCIA setzt. Vorteil: Ich kann auch 2.2er Kernel booten und habe PCMCIA. Evtl. geht es auch (untested), wenn man verschiedene modules.conf für die installierten Kernel verwendet (siehe D. Hallers Multikernel-Howto) da in die 2.4er modules.conf ein alias i82365 yenta_socket zu schreiben. Auf jeden Fall sollte man für 2.4er Kernel mindestens pcmcia_cs Version 3.1.21 verwenden. Gruß Christoph -- Christoph Maurer - Paul-Röntgen-Straße 7 - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
On Wed, Sep 12, Andreas Kretzer wrote:
Heute hier mal eine interessante Erkenntnis:
Lange habe ich versucht, den PCMCIA-Krempel meiner SuSE 7.2 zum Laufen zu kriegen. Mit dem SuSE-Original Kernel und den beigepackten Modulen geht's, mit dem selbst übersetzten Kernel: Fehlanzeige!
Das Modul i82365 kann nicht geladen werden: Intel PCIC-Probe: not found Irgenwann fiel mir auf, dass meine PCMCIA-Version (dmesg) nicht mit der übereinstimmt, die man beim booten des SuSE-Kernels zu sehen bekommt. Außerdem war in der Konfiguration des SuSE- Kernels gar kein PCMCIA eingebaut!
Des Rätsels Lösung: SuSE verwendet das externe PCMCIA-Package (Sourcen auf der DVD / den CDs). Wenn man diese installiert und sich das README-2.4 durchliest, sieht man warum es mit eingebautem PCMCIA so gar nicht gehen kann:
statt des Moduls 'i82365' verwende man für Kernel-basiertes PCMCIA doch bitte das Modul 'yenta_socket'
Gesagt - getan ... und schon klappts auch so. Man muß also nur statt des einen das andere Modul laden. Die Anpassung im Start- skript '/etc/init.d/pcmcia' ist allerdings nicht so offensichtlich. Da wird mit '/sbin/probe -m' der Controller-Typ ausgelesen und in die Variable PCMCIA gesetzt. und genau dieses Modul wird dann per 'modprobe' geladen. Man kann also ein
PCMCIA=yenta_socket
hinter die Abfrage '/sbin/probe -m' setzen und alles läuft bestens. Ich habe allerdings in /etc/rc.config einfach noch ein PCMCIA_YENTA_SOCKET=yes eingefügt und eine Abfrage ins Startskript eingebaut, die den Wert von PCMCIA auf yenta_socket setzt, falls er vorher i82365 war und PCMCIA_YENTA_SOCKET auf 'yes' steht.
Noch eleganter wäre vielleicht der Versuch, bei fehlgeschlagenem Laden des i82365-Moduls einfach probehalber das Yenta- Modul zu laden.
Es geht ganz elegant und einfach: PCMCIA=yenta_socket in rc.config Das genügt. Sonst muß nichts geändert werden. Dann funktionieren mit Kernel PCMCIA für CArdBus Karten aber die Konfigurationsscripte unter /etc/pcmcia nicht mehr. Das ist konzeptionell bedingt und sollte via HOTPLUG gemanagt werden. Wem das nicht gefällt und die Konfiguration wie bisher haben möchte, der kann die folgende Alternative verwenden. Alternative: ^^^^^^^^^^^^ Unter ftp.suse.com:/pub/people/zoz/pcmcia/7.2-i386/experimental/ liegt (*) ein pcmcia 3.1.28 das für beide PCMCIA Systeme vorbereitet ist. Kurzanleitung: - eigenen Kernel mit CONFIG_PCMCIA=y übersetzen - rpm --rebuild pcmcia-3.1.28-0.src.rpm - cd /usr/src/packages/RPMS/i386/ - rcpcmcia stop - rpm -Uhv pcmcia-3.1.28-0.i386.rpm - rpm -hiv --force pcmcia-modules-3.1.28_* - 'rcpcmcia start' oder 'rcpcmcia start kernel' ( (*) = werden da liegen, nachdem der ftp server das nächste mal aktualisiert wird. Das geschieht normalerweise mehrmals täglich. ) Fehlerreports sind sehr willkommen! Das ganze soll nämlich so in das nächste SuSE Lnux eingebaut werden. Unter /usr/share/doc/packages/pcmcia/ befindet sich ein LIESMICH.SuSE, das die Änderungen kurz beschreibt. Ich poste es hier einfach mal: Besonderheiten im PCMCIA Paket von SuSE Linux 7.3 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1) Die Wahl des PCMCIA Systems Zur Zeit gibt es zwei PCMCIA Systeme. Das bisherige von D. Hinds, das nicht in den Kernel integriert wurde (Externes PCMCIA) und das neuere im Kernel enthaltene (Kernel PCMCIA). Das Externe ist erprobt und enthält Treiber, die (noch) nicht in das Kernel PCMCIA übernommen wurden. Andererseits gibt es auch (neue) Hardware, die vom Kernel PCMCIA besser unterstützt wird. Bei SuSE Linux 7.3 ist es möglich beide Syteme wahlweise zu verwenden, ohne einen anderen Kernel dafür booten zu müssen. Dafür gibt es in /etc/rc.config.d/pcmcia.rc.config eine Variable PCMCIA_SYSTEM, die entweder auf "external" oder "kernel" gesetzt wird. Wird PCMCIA manuell gestartet, kann das gewünschte System als zweiter Parameter übergeben werden: rcpcmcia start {external|kernel} rcpcmcia restart {external|kernel} Wird kein Parameter übergeben oder ist PCMCIA_SYSTEM leer wird das Externe System gestartet. Sollte nur eines der beiden Systeme verfügbar sein (selbstkomplilierter Kernel, etc.), dann wird unabhängig von der Wahl des Systems das gerade verfügbare gestartet. 2) Module für die PC-Card/CardBus-Bridges Bei beiden PCMCIA Systemen gibt es verschiedene Module für die PC-Card/CardBus-Bridges. Beim Externen i82365 und tcic; beim Kernel yenta_socket, i82365 und tcic. tcic ist für exotische Hardware und hier nicht von Bedeutung. i82365 ist das übliche Modul beim Externen PCMCIA und das neue yenta_socket das Modul für Kernel PCMCIA. Im Normalfall wird dieses Modul automatisch vom Startscript ermittelt. Falls dies fehlschlägt, kann in /etc/rc.config.d/pcmcia.rc.config die Variable PCMCIA_PCIC verwendet werden. Dort kann das gewünschte Modul eingetragen werden. 3) Parameter für die Basismodule Werden für die Basismodule spezielle Parameter benötigt, können diese wie bisher in /etc/rc.config.d/pcmcia.rc.config in die Variablen PCMCIA_CORE_OPTS (für pcmcia_core) und PCMCIA_PCIC_OPTS (für yenta_socket, i82365 bzw. tcic) eingetragen werden. 4) Unterschiedliche Treiberzuordnungen der beiden Systeme Wie bisher befindet sich die Zuordnung von Treibern zu PCMCIA Karten in den Dateien /etc/pcmcia/config und /etc/pcmcia/*.conf (wobei Einträge in den *.conf die in config überschreiben). Da für Kernel PCMCIA eine nur teilweise andere Zuordnung nötig ist, wird im Falle von Kernel PCMCIA zusätzlich die Datei /etc/pcmcia/config.add_kernel gelesen. Die Einträge in dieser Datei überschreiben die aus config und *.conf, so daß nur die Karten/Treiber eingetragen werden müssen, bei denen sich die zwei Systeme unterscheiden. 5) Parameter für Kartenmodule Parameter für Kartenmodule werden wie bisher in /etc/pcmcia/config.opts abgelegt. Falls für Module, die in /etc/pcmcia/config.add_kernel zugeordnet werden, Parameter notwendig sind, können diese in /etc/pcmcia/config.add_kernel.opts eingetragen werden. 6) Der card manager (cardmgr) Der cardmgr aus dem Externen PCMCIA wird für beide Systeme benötigt. Er wird mit den notwendigen Optionen für das jeweilige System im PCMCIA Startscript gestartet. Diese Optionen sind im wesentlichen "-n <modsubdir>" und "-k". Mit -n wird das Unterverzeichnis zu /lib/modules/<kernel-version>/ angegeben, aus dem die Module für PCMCIA Karten bevorzugt geladen werden (mittels insmod). Ist in diesem Unterverzeichnis kein entsprechendes Modul vorhanden, wird (mittels modprobe) an anderer Stelle nach diesem Modul gesucht. -k veranlasst den cardmgr, die zusätzliche Konfigurationsdatei /etc/pcmcia/config.add_kernel zu lesen. 6) Kernel PCMCIA und CardBus Karten CardBus Karten sind erweiterte PCI Geräte. Deshalb verwendet das Kernel PCMCIA (mit Ausnahmen) keine besonderen PCMCIA Module, sondern die gewöhnlichen PCI Module, die auch für PCI Karten mit entsprechendem Chip verwendet werden. Diese werden konzeptionell nicht vom cardmgr sondern vom /sbin/hotplug eingerichtet. Da das Hotplug Paket auf SuSE Linux 7.3 noch nicht so flexibel in der Konfiguration ist wie die scripte unter /etc/pcmcia, wurde das PCMCIA Paket dehingehend geändert, daß auch CardBus Karten bei Kernel PCMCIA vom cardmgr konfiguriert werden. Deshalb sollten die Variablen HOTPLUG_START_PCI und HOTPLUG_START_NET in /etc/rc.config.d/hotplug.rc.config beide auf "no" gesetzt sein (falls Hotplug überhaupt installiert ist). -- ciao, christian ---------------------------------------------------------------- ... und sie sägten an den Ästen, auf denen sie saßen und schrien sich Ihre Erfahrungen zu, wie man besser sägen könne ... ---(Haindling)--------------------------------------------------
participants (3)
-
Andreas Kretzer
-
Christian Zoz
-
Christoph Maurer