Mailinglist Archive: opensuse-de (1579 mails)

[Richard Kampmann <Richard.Kampmann@xxxxxxxxxx>]

Hallo,

ich meine, daß mein kleines Problem ein Problem des Modulhandlings ist und 
kein spezifisches ISDN-Problem, auch wenn es sich um CAPI-Module handelt.

Leider muß ich das kurzfristig (spätestens morgen), ob dies nun sauber 
oder "schmutzig" passiert.

Hintergrund:
Ich habe hier einen älteren Rechner, der unter openSUSE 10.2 mit einer AVM 
Fritzcard 2.0 DSL über ISDN (!) ans Internet gehen soll.

Leider gibt es von AVM keine CAPI-Treiber mehr direkt für den Kernel
2.6.18.8-0.3-default
Also habe ich mir folgende Pakete besorgt und installiert:
capisuite-0.4.5-45
fcdsl2-fw-3.11-1
fcdsl2-kmp-default-0.1_2.6.18.8_0.1-0
drdsl-1.0-1

Wenn nun folgende Module geladen sind
capi                   21824  0
capidrv                32308  0
kernelcapi             50688  2 capi,capidrv
isdn                  134752  1 capidrv
capifs                  9992  2 capi

Dann kann ich mich auch mit Hilfe von Kinternet problemlos einwählen. Die 
grundsätzliche Funktionalität ist also gegeben.
Der Rechner soll aber leider DAU-fähig werden, und die Module laden nicht 
alle "freiwillig".

Folgende Abhängigkeiten finden sich in den Modulen (modinfo) und werden 
mit 'depmod -a' auch richtig in die 'modules.dep' geschrieben:

capidrv
      - kernelcapi
      - isdn
            - slhc
capi
      - capifs
      - kernelcapi

Auffällig ist hier auch, daß die im Modul (und in der modules.dep) sichtbaren 
Abhängigkeiten von capi (capifs, kernelcapi) nicht beim lsmod sichtbar sind, 
wenn capi per Hand nachgeladen wird.

capidrv, isdn und kernelcapi laden normal beim Booten - jedenfalls nach 
Eintrag der Zeilen 

alias char-major-43       capidrv
alias char-major-44       capidrv
alias char-major-45       capidrv

in die /etc/modules.conf.local

Das gilt aber leider nicht für capi und capifs.

Trage ich nun 'per Hand' in die modules.dep ein, daß capidrv auch von capi und 
capifs abhängig sei, so wird tatsächlich sogar capifs automatisch geladen. 
Leider aber nicht capi.
Dies läßt sich aber nachträglich mit einem 'modprobe capi' problemlos und ohne 
Fehler erledigen.

Auch wenn ich über Yast den Zugang neu konfiguriere (nur mit einer scheinbaren 
Änderung, so daß der abschließende Konfig-Lauf angestoßen wird), ist das 
capi-Modul geladen. ein SuSEconfig alleine tut es nicht - was macht Yast hier 
noch mehr?

Es ist ja schon unsauber, so eine per Hand editierte modules.dep zu verwenden, 
da das ja beim nächsten Update sicherlich schiefgeht. Aber der vorgesehene 
User ist sicher nicht in der Lage, manuell jedesmall das Modul capi 
nachzuladen. Wäre schön, wenn capi geladen würde und automatisch über die 
Abhängigkeit auch capifs anziehen würde.

Jetzt kann ich das natürlich irgendwo scripten und auf diese Weise nachziehen, 
aber ich verstehe nicht recht, warum das Modul nicht geladen wird, obwohl es 
im richtigen Kernelbaum liegt, die richtigen Abhängigkeiten hat usw.

/lib/modules/2.6.18.8-0.3-default/kernel/drivers/isdn/capi/capi.ko
/lib/modules/2.6.18.8-0.3-default/kernel/drivers/isdn/capi/kernelcapi.ko
/lib/modules/2.6.18.8-0.3-default/kernel/drivers/isdn/capi/capifs.ko
/lib/modules/2.6.18.8-0.3-default/kernel/drivers/isdn/capi/capidrv.ko
/lib/modules/2.6.18.8-0.3-default/kernel/drivers/isdn/i4l/isdn.ko

Wie gesagt - alles außer capi lädt jetzt automatisch (wenn auch etwas 
unsauber) und capi läßt sich manuell problemlos nachladen.

So - wo nun stehe ich auf dem Schlauch?

Gruß

Richard