# capi4k-utils funktioniert nach Kernel-Upgrade nicht [gelöst]

## sprittwicht

Hallo!

Ich bin's wieder mit meinem halbjährlichen ISDN-Problem. Diesmal hab ich lediglich ein winziges Kernelupgrade gewagt (gentoo-sources-2.6.11-r5 -> 2.6.11-r6), danach ging nichts mehr. Während dem Booten erscheint ja normalerweise nach "Starting CAPI" (oder so ähnlich) eine Auflistung aller gefundenen ISDN-Controller, in meinem Fall ein AVM FritzX USB. Das Gerät wurde nicht mehr nach dem Booten des neuen Kernels aufgelistet, mit dem immer noch startbaren Vorgängerkernel lief es aber ohne Probleme.

Dumm wie ich war dachte ich dann: Mach ein capi4k-utils-Update. Die neuere Version stand nämlich schon länger in den Startlöchern, aber ich hatte berechtigterweise Angst vor dem Update. Also jetzt aber den Sprung von capik4-utils-20041006-r3 auf 20041006-r5 gewagt und bumms. Nun wird das Modem weder bei Verwendung des alten noch des neuen Kernels erkannt.

Ich benutze das fxusb-Modul aus fritzcapi-2.6.32 und habe diverse Einstellungen probiert (Modul selbst starten per /etc/modules.autoload.d/kernel-2.6, automatische Erkennung), es will einfach nicht mehr.

Als erste Merkwürdigkeit in /var/log/messages fiel mir auf, dass sich der Kernel beim Anschließen des Modems plötzlich beschwert hat:

```
modprobe: FATAL: Module capidrv not found.
```

Also hab ich capidrv mit in den Kernel gepackt, obwohl ich das vorher noch NIE musste. ??

Hat aber auch nichts gebracht.

capiinfo meldet:

```
capi not installed - No such device or address (6)
```

Das Einwählen via ppp-dial (Script, das glaub noch vom nicht mehr benutzten teledat-Treiber stammt) liefert:

```
Plugin userpass.so loaded.

userpass: $Revision: 1.5 $

Plugin capiplugin.so loaded.

capiplugin: $Revision: 1.36 $

capiconn:  1.10 

capiplugin: CAPI_REGISTER failed - CAPI not installed (0x1009) [No such device or address (6)]
```

Ein kleiner Auszug aus meiner Kernel-Config:

```
#

# ISDN subsystem

#

CONFIG_ISDN=m

#

# Old ISDN4Linux

#

CONFIG_ISDN_I4L=m

# CONFIG_ISDN_PPP is not set

# CONFIG_ISDN_AUDIO is not set

#

# ISDN feature submodules

#

# CONFIG_ISDN_DRV_LOOP is not set

# CONFIG_ISDN_DIVERSION is not set

#

# ISDN4Linux hardware drivers

#

#

# Passive cards

#

# CONFIG_ISDN_DRV_HISAX is not set

#

# Active cards

#

# CONFIG_ISDN_DRV_TPAM is not set

# CONFIG_HYSDN is not set

#

# CAPI subsystem

#

CONFIG_ISDN_CAPI=m

CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y

CONFIG_ISDN_CAPI_MIDDLEWARE=y

CONFIG_ISDN_CAPI_CAPI20=m

CONFIG_ISDN_CAPI_CAPIFS_BOOL=y

CONFIG_ISDN_CAPI_CAPIFS=m

CONFIG_ISDN_CAPI_CAPIDRV=m

#

# CAPI hardware drivers

#

#

# Active AVM cards

#

# CONFIG_CAPI_AVM is not set

#

# Active Eicon DIVA Server cards

#

# CONFIG_CAPI_EICON is not set
```

Kann sich jemand einen Reim drauf machen? Ist übrigens ein udev-System.

Kann alternativ mal jemand die /etc/init.d/capi aus capik4-utils-20041006-r3 posten? Da hat es anscheinend zwischen r3 und r5 recht gravierende Änderungen gegeben.Last edited by sprittwicht on Sat May 14, 2005 8:05 pm; edited 1 time in total

----------

## sbriesen

2.6.11-gentoo-r6 auf 3 Kisten und alles mit capi4k-utils-20050322-r1.

Die verschiedensten ISDN-Karten (aktiv/passive) im Betrieb, sowohl 'fritzcapi', als auch mISDN. Keinerlei Probleme.

Also muss was anderes das Problem bei Dir Verurachen.

mach nach dem capi4k-utils emerge unbedingt ein etc-update. Dann prüfe mach den /dev/capi20 Device-Node, ob der da ist und mit welchen Rechten.

Dann schauen wir mal, ob wir das Problem bei Dir finden...

----------

## sbriesen

gaaaaaanz dumme Frage: hast Du 'fritzcapi' nach dem Kernel-Update neu emerged?`Das muss man natürlich machen, denn die Module werden ja immer nur für den aktuellen Kernel gebaut. Beim Kernel-Update muss man *immer* auch alle 3rd-Party module neu emergen.

Nur so als Idee....

----------

## sbriesen

schau mal bitte in dieses Verzeichnis:

/lib/modules/2.6.11-gentoo-r6/extra

liegen da alle notwendigen AVM-treiber rum? Wenn nicht, dann war es das schon.

----------

## sprittwicht

Die Fritzcapi-Module hab ich neu kompiliert nach dem Upgrade. fxusb wird auch anstandslos (ohne Fehlermeldungen) geladen und es gibt die Devicenode /dev/capi20. Allerdings scheint die nicht wirklich mit einem Gerät verknüpft zu sein, denn wenn ich z.B. ganz blöde mit cat /dev/capi20 drauf zugreife (recht sinnfrei, ich weiß  :Smile:  ), dann kommt ne Meldung "kein Gerät gefunden" oder so ähnlich.

Allerdings findet sich in der Ausgabe von dmesg unter anderem:

```
capi20: Rev 1.1.2.7: started up with major 68 (middleware+capifs)
```

Was ich halt seltsam finde, dass es mit dem alten Kernel zunächst ging, nach dem capi4k-utils Update aber nicht mehr. Da kann sich doch bei einem so winzigen Update (nicht die Version des Pakets selbst, sondern nur das "-r??" dahinter) nicht soviel ändern, dass plötzlich gar nichts mehr geht? Und beim Kernel erst recht nicht, dachte ich. :-/

Weiß jemand, was zwischen capi4k-utils-20041006-r3 und r5 passiert ist?

Hier mal alle relevanten dmesg-Meldungen:

```
CAPI Subsystem Rev 1.1.2.8

fxusb: AVM FRITZ!X USB/FRITZ!X ISDN driver, revision 0.5.2

fxusb: (fxusb built on Apr 30 2005 at 23:26:50)

fxusb: Loading...

usb 1-1: new full speed USB device using ohci_hcd and address 2

usb 1-3: new low speed USB device using ohci_hcd and address 3

usbcore: registered new driver fxusb

fxusb: Loaded.

.................

capifs: Rev 1.1.2.3

capi20: Rev 1.1.2.7: started up with major 68 (middleware+capifs)

ISDN subsystem Rev: 1.1.2.3/1.1.2.3/1.1.2.2/none/none/1.1.2.2 loaded

capidrv: Rev 1.1.2.2: loaded
```

Könnt ihr vielleicht mal gucken, ob in eurer "ISDN subsystem Rev" auch "none/none" auftaucht? Irritiert mich gerade spontan etwas.

PS: Sorry dass ich die meisten Fehlermeldungen nur mit "oder so ähnlich" umschreiben kann. Sitze aber derzeit nicht an dem Rechner und kann daher fast nur Gedächtnisprotokolle abliefern...

----------

## sbriesen

Die capi4k-utils scheinen nicht wirklich Dein Problem zu sein. Denn diese sind nur die Userland-Utilities + CAPI Library. Alles andere läuft im Kernel ab.

Wenn Du

  cat /proc/capi/controller

machst und nichts siehst, dann stimmt irgendwas mit den Kernel-Modulen nicht.

Schalte mal in /etc/conf.d/capi das CAPI_USB_HOTPLUG auf "0", bzw. "no" (je nach capi4k-utils version). Dann mal sicherheitshalber booten, oder anderweitig sicherstellen, dass *keine* CAPI/Karten-Treiber mehr geladen sind.

Nun kannst Du den Ladeprozess mal testweise manuell machen:

  modprobe -v capi

  modprobe -v <card-driver>

spätestens dann sollte "cat /proc/capi/controller" funktionieren. Wenn Du soweit kommst, hast Du schon praktisch gewonnen.

----------

## sbriesen

btw:

CAPI Subsystem Rev 1.1.2.8

capifs: Rev 1.1.2.3

capi20: Rev 1.1.2.7: started up with major 68 (middleware+capifs)

kcapi: Controller 1: c2-d400 attached

kcapi: Controller 2: c2-d400 attached

Modular ISDN Stack core $Revision: 1.25 $

mISDNd: kernel daemon started

ISDN L1 driver version 1.11

ISDN L2 driver version 1.20

mISDN: DSS1 Rev. 1.28

mISDN Capi 2.0 driver file version 1.14

mISDN: sedlpci found adapter Sedlbauer Speedfax + PCI at 0000:00:09.0

kcapi: Controller 3: mISDN1 attached

mISDNd: test event done

mISDN_isac_init: ISAC version (0): 2086/2186 V1.1

mISDN: ISAR driver Rev. 1.20

mISDN: ISAR driver Rev. 1.20

kcapi: card 1 "c2-d400" ready.

kcapi: card 2 "c2-d400" ready.

ISDN subsystem Rev: 1.1.2.3/1.1.2.3/1.1.2.2/1.1.2.3/1.1.2.2/1.1.2.2 loaded

capidrv-1: now up (2 B channels)

capidrv-1: D2 trace enabled

capidrv-2: now up (2 B channels)

capidrv-2: D2 trace enabled

capidrv: Rev 1.1.2.2: loaded

ABER: 'capidrv' ist völlig irrelevant fürs erste. Erst muss CAPI laufen, *dann* kann man sich um I4L kümmern.

----------

## sbriesen

cat /proc/capi/controller

```

    1 c4         running  c2-d400          C2 3.11-06 0xd400 217 0xfebffc00

    2 c4         running  c2-d400          C2 3.11-06 0xd400 217 0xfebffc00

    3 mISDN      running  mISDN1           -

```

----------

## sprittwicht

Erstmal danke für deine Tips.

Hier ist meine Ausgabe von cat /proc/capi/controller:

```
 
```

 :Sad: 

cat /proc/capi/driver gibt mir aber "fxusb-(aktuelle Version)", weder fxusb noch capi beschweren sich bei einem modprobe in irgendeiner Form. Ich hab keinen Dunst wo ich noch suchen könnte.

Kann es sein dass das Modem spontan den Geist aufgegeben hat?

EDIT:

capidrv war bei mir bislang auch völlig irrelevant, da ich auch gar keine "alten" isdn4linux-Programme benutze. Wie gesagt verlangte modprobe plötzlich danach. Ich werd daraus nicht schlau.

Kannst du trotz allem mal deine /etc/init.d/capi posten?

----------

## sprittwicht

 *sprittwicht wrote:*   

> Kannst du trotz allem mal deine /etc/init.d/capi posten?

 

Das war natürlich Quatsch, da deine Version eh in Portage drin ist.

Hat noch jemand die alte Version der /etc/init.d/capi aus capik4-utils-20041006-r3? Bin echt für jeden Strohhalm dankbar.

----------

## genstef

Wie wärs denn mit deiner /etc/capi.conf und /etc/conf.d/capi?

lädst du das modul mit hotplug oder /etc/init.d/capi start?

----------

## sprittwicht

An die Dateien komm ich gerade nicht dran, heute Abend vielleicht. Kann im Moment nur sagen dass ich beides probiert habe: Über Hotplug und über den Eintrag in /etc/capi.conf.

Ich weiß jetzt ehrlich gesagt nicht mehr, ob eine dieser beiden Varianten überhaupt mal funktioniert hat. Zumindest per Hotplug ging es nicht, glaube ich. Um auf Nummer Sicher zu gehen, hab ich fxusb immer über die /etc/modules.autoload.d/kernel-2.6 geladen.

Wer ist denn eigentlich dafür verantwortlich, dass beim Einstöpseln des Modems seit neuestem das capidrv-Modul geladen werden soll? Irgendwer muss das dem Kernel doch sagen. Hotplug? Das fxusb-Modul beim Laden selbst?

Bietet das fxusb-Modul irgendwelche besonderen Debug-Optinen, die mir noch ein paar aufschlussreiche Meldungen um die Ohren knallen könnten?

Kann ich jenseits der ganzen Capi-Querelen das Modem direkt testen, ob es eventuell defekt ist?

----------

## sprittwicht

Aaaaaalso:

/etc/conf.d/capi sagt jetzt:

CAPI_HOTPLUG_USB=1

CAPI_HOTPLUG_BEEP=1

In /etc/capi.conf ist nur die Zeile mit fxusb aktiviert, in der autoload.d/kernel-2.6 hab ich fxusb auskommentiert.

Zu meiner Überraschung funktioniert Hotplug und die gewünschten Module werden alle ohne Fehlermeldungen geladen. Allerdings Funktioniert das Gerät immer noch nicht.

Ich sollte noch erwähnen dass das Problem offenbar im fritzcapi-Treiber zu suchen ist, da am Modem die LED, die normalerweise permanent leuchtet, sobald das Gerät erkannt wurde, zwar beim Hochfahren angeht, sich jedoch nach einiger Zeit abschaltet.

----------

## sbriesen

'capidrv' wird deswegen geladen, weil das in /etc/init.d/capi bzw. /etc/hotplug/usb/capi so drinnen steht.  :Wink:  Das ist ein Feature, kein Bug!

man kann es aber auch abschalten in /etc/conf.d/capi

```

# should CAPIDRV be loaded?

CAPI_LOAD_CAPIDRV="no"

```

Keinesfalls solltest Du irgendwas in autoload.d eintragen.

Wenn ich das richtig sehe, braucht die fxusb keinerlei Firmware? Wenn dem so wäre, wüsste ich wo der Fehler liegt...  :Wink: 

Allerdings müsste nach Laden des Moduls auf jedenfall was mit

```

cat /proc/capi/controller

```

zu sehen sein. Ich denke auch nicht, dass irgendwas an capi4k-utils oder den init/hotplug-scripten was nicht in Ordnung ist.

@genstef: kann da was mit den fritzcapi-Modulen was im argen sein?

----------

## sbriesen

sekunde mal, da fällt mir grad was auf.

Der von Dir gepostete /etc/conf.d/capi Schnipsel passt nicht zur aktuellesten capi4k-utils Version im Portage. Die müsste anders aussehen.  :Wink: 

Welche Version setzt Du ein?

mach mal:

```

emerge sync

ACCEPT_KEYWORDS="~x86" emerge capi4k-utils

```

und danach *unbedingt*:

```

etc-update

```

und update alle capi relevanten files.

Dann bitte nochmals testen.

----------

## sprittwicht

Richtig, fxusb braucht (meines Wissens nach) keine Firmware. Na spann mich nicht auf die Folter, was ist deine Vermutung für den Fehler?  :Smile: 

Der Schnippsel passt zu meiner Version capi4k-utils-20041006-r5, in der es auch noch nicht die Option zum Abschalten von capidrv gibt. Die aktuellste Version von capi4k-utils hätte ich am liebsten schon letzte Woche installiert, aber ohne Internet gestaltet sich so ein Update recht schwierig.  :Confused: 

Ich werde erst nächstes Wochenende wieder selbst an den Rechner kommen, dann wird der mit der aktuellen Version versorgt.

Falls euch bis dahin noch irgendwas einfällt bitte posten, ansonsten bedank ich mich erstmal für eure Mühen und melde mich nächstes Wochenende wieder. Dann hoffentlich vom anderen Rechner aus.

----------

## sbriesen

nun, meine Vermutug war schlicht: im hotplug-script wird keine Firmware angezogen. Sollte die nämlich notwendig sein, dann funzt die Karte schlicht nicht, ABER: in /proc/capi/controller taucht diese dann dennoch auf. Nur eben mit dem status "detected" anstatt "running".

Aber Deine Fehlerbeschreibung ist dann doch gänzlich anders. Wenn gar nix in /proc/capi/controller auftaucht, dann ist da was anderes faul.

Wie gesagt: bitte update mal auf die 2005er Version von capi4k-utils (etc-update nicht vergessen!). Da die 2005er aber eine API/API-Änderung erfahren hat, musst Du alle auf CAPI aufbauenden Pakete nochmals re-emergen, damit die sauber gegen die neue Version linken. Ein revdep-rebuild sollte helfen...  :Wink: 

----------

## sprittwicht

Tja, läuft immer noch nicht.  :Sad: 

Hab jetzt mal die 2005er Version installiert und die Config-Dateien auf den neuesten Stand gebracht, aber es tut sich nichts. Immerhin hab ich das Modem jetzt unter Windows ans Laufen gekriegt, also ist das Gerät zumindest in Ordnung.

Was kann ich noch tun? Viel Auswahl bleibt jawohl nicht mehr... :-/

----------

## sprittwicht

Hm, eine mögliche Lösung ist im Anmarsch, allerdings verwirrt mich das jetzt noch mehr:

Anscheinend versuche ich die ganze Zeit, den falschen Treiber zu benutzen. lsusb liefert mir als Geräte-ID "057c:2800", demnach müsste ich wohl das OEM-Modul fxusb_cz nehmen, NICHT fxusb.

Wahrscheinlich hab ich bisher zwar in der autoload.d/kernel-2.6 den fxusb-Treiber geladen, aber später wurde dann automatisch der _cz nachgeladen und benutzt. Das wäre momentan meine einzige logische Erklärung.

ABER:

Das würde voraussetzen, dass das fxusb_cz-Modul bisher immer mitgebaut wurde. Da ich gerade natürlich als erstes dieses Modul ausprobieren wollte hab ich aber festgestellt, dass es gar nicht installiert ist. Obwohl ich keine Einschränkungen in der make.conf gemacht hatte, also alle Module hätten gebaut werden sollen. Jetzt hab ich das Modul ausdrücklich in der make.conf eingetragen und es wird überhaupt kein Treiber mehr gebaut! Öhm... Hm?

Wie kann ich den fritzcapi-Ebuild dazu bringen, das Modul fxusb_cz zu installieren?

Könnte es auch sein, dass bisher doch das fxusb-Modul benutzt wurde und erst mit der neuen Version der capi4k-utils Inkompatibilitäten auftreten, die die Benutzung des OEM-Moduls erforderlich machen? Das macht doch irgendwie überhaupt keinen Sinn, wieso lief das früher? Ich raff's nicht.

----------

## sbriesen

> Wie kann ich den fritzcapi-Ebuild dazu bringen, das Modul fxusb_cz zu installieren? 

FRITZCAPI_CARDS="fxusb_cz" emerge fritzcapi

oder einfach FRITZCAPI_CARDS leer lassen, dann installiert er alle Treiber (sofern 'usb' in den USE-Flags steht in Deinem Fall).

nur die fxusb_cz ist irgend so ne Sondervariante. Die ist eigentlich nicht für Deutschland gedacht. Da wird ne README mit dem Treiber zusammen installiert, les die mal durch.

Es wäre denkbar, dass da irgendwie die USB-IDs "klemmen" oder falsch zugeordnet sind. Hmmm... sehr merkwürdig.

----------

## genstef

 *sbriesen wrote:*   

> > Wie kann ich den fritzcapi-Ebuild dazu bringen, das Modul fxusb_cz zu installieren? 
> 
> FRITZCAPI_CARDS="fxusb_cz" emerge fritzcapi
> 
> oder einfach FRITZCAPI_CARDS leer lassen, dann installiert er alle Treiber (sofern 'usb' in den USE-Flags steht in Deinem Fall).
> ...

 

Das Problem ist, dass das modul fxusb_CZ und nciht etwa fxusb_cz heißt  :Sad: 

Sorry, das ist meine Schuld, ich habe es gerade im cvs behoben, ansonsten einfach alle cz im ebuild gross machen:

sed -i "s/cz/CZ/" /path/to/fritzcapi.ebuild

oder in ein/zwei stunden emerge sync machen.

Danach

FRITZCAPI_CARDS="fxusb_CZ" emerge fritzcapi

(Man bemerke das große CZ)

    14 May 2005; Stefan Schweizer <genstef <at> gentoo.org>

  fritzcapi-2.6.32.ebuild:

  Fix bug fxusb_CZ not installed, found in

https://forums.gentoo.org/viewtopic-t-332961.html thanks to sprittwicht

----------

## sprittwicht

Ja, das hab ich ja beides probiert (leer lassen und fxusb_cz eintragen), das Modul wurde aber nicht mitgebaut. usb in den USE-Flags ist gesetzt.

Das mit der tschechischen Telekom hab ich auch (mit einigem Entsetzen  :Smile:  ) gelesen. Sicher, dass der ausdrücklich nicht für Deutschland gedacht ist? Ich dachte dass das tschechische Gerät vielleicht baugleich mit der deutschen OEM-Fassung ist, weil der Treiber in der capi.conf auch als OEM beschrieben wird. Das Modem war damals bei einem "1&1 NetXXL"-Paket dabei.

----------

## sbriesen

Stefan Schweizer (genstef) teilt mir gerade mit, dass da wohl tatsächlich ein Bug in dem fritzcapi-ebuild ist, der das bauen des moduls verhindert (nur nen Tippfehler oder sowas).  Er wird das schnellst möglich fixen, denke ich.

Was das OEM angeht: klingt eigentlich logisch was Du sagst...  :Wink: 

----------

## sprittwicht

JUHUUUUUUUUUUU!!!!!!!!!!!!!!!!!  :Very Happy: 

Mit dem korrigierten Ebuild klappt's wunderbar, danke!

Allerdings bedeutet das, dass ich früher definitiv noch nie den _CZ-Treiber installiert hatte. Weshalb ich also trotz falschem Treiber mit den alten capi4k-utils ins Internet kam, wird wohl für immer ein ungelöstes Rätsel bleiben.

Per Hotplug geht's übrigens nicht, aber über die /etc/capi.conf läuft's jetzt bestens.

Nochmal ein dickes Dankeschön an die beiden Stefans.  :Smile: 

----------

## sbriesen

was waren nochmal die USB-IDs? Die müsste man dann im hotplug-script ggf. anpassen, damit er das richtig anzieht. Sieht nämlich so aus, dass Du zwar den *_CZ Treiber brauchst, aber ne vollkommen andere ID hast als die CZ-Version.  :Wink: 

Das wäre aber dann leicht zu fixen...

----------

## sprittwicht

Meinst du die IDs in /etc/hotplug/usb/capi? Die sind korrekt:

```
        "057c/2800") # FRITZX!USB OEM

                DRIVER="fxusb_CZ"[
```

Das deckt sich mit meiner Karte.

Kann udev Schuld am Nichtladen sein? Wann wird denn dieses USB-CAPI-Script überhaupt abgearbeitet?

----------

## sbriesen

1. prima

2. udev kann nicht schuld sein (zumindest sollte es das nicht)

3. mit coldplug beim booten, oder wenn hotplug Dein Device am Bus entdeckt.

nimm mal den Eintrag aus capi.conf raus und stecke die Box ab. Entlade den Treiber. /proc/capi/controller sollte nix mehr anzeigen. Nun mach mal "tail -f /var/log/messages" und steck die Box wieder ein. "capi-usb" sollte sich melden.

----------

## sprittwicht

Da regt sich nichts. Hab den Eintrag in capi.conf auskommentiert und in conf.d/capi CAPI_HOTPLUG_USB auf "yes" gesetzt.

Alles was ich kriege wenn ich das Modem rausziehe und wieder anschließe:

```
May 15 10:08:44 gronk usb 1-1: USB disconnect, address 2

May 15 10:08:53 gronk usb 1-1: new full speed USB device using ohci_hcd and address 3
```

fxusb_CZ wird aber nicht geladen.

Aber folgendes erscheint, wenn ich dann fxusb_CZ per modprobe lade:

```
May 15 10:13:00 gronk fxusb_CZ: OEM FRITZ!X USB driver, revision 0.5.0

May 15 10:13:00 gronk fxusb_CZ: (fxusb_CZ built on May 14 2005 at 20:03:54)

May 15 10:13:00 gronk fxusb_CZ: Loading...

May 15 10:13:00 gronk fxusb: WARNG: Driver and stack name do not match!

May 15 10:13:00 gronk fxusb: Driver 'fxusb_CZ' attached to stack. (152)

May 15 10:13:00 gronk fxusb_CZ: Stack version 3.11-04

May 15 10:13:00 gronk kcapi: Controller 1: fxusb_CZ-0003 attached

May 15 10:13:00 gronk kcapi: card 1 "fxusb_CZ-0003" ready.

May 15 10:13:00 gronk usbcore: registered new driver fxusb_CZ

May 15 10:13:00 gronk fxusb_CZ: Loaded.
```

Also irgendwie kommt er vom "original" fxusb nicht los.  :Smile: 

Aber ich denke das hat wenig mit hotplug zu tun sondern mehr damit, dass im gepatchten, vom original fxusb abgeleiteten Treiber halt noch der alte Name drinsteht.

----------

## sbriesen

nein, das glaube ich nicht. Hotplug scheint die ID nicht zu kennen, weswegen schlicht nix passiert. Also schauen wir doch mal, wo überall der Treiber drinstehen muss.

1. /etc/hotplug/blacklist.d/capi

   hiermit wird verhindert, dass hotplug den Treiber selbst läd.

   Das ist wichtig, damit wir die anderen capi-module in einem eigenen

   script laden können.

2. /etc/hotplug/usb/nein, das glaube ich nicht. Hotplug scheint die ID nicht zu kennen, weswegen schlicht nix passiert. Also schauen wir doch mal, wo überall der Treiber drinstehen muss. 

1. /etc/hotplug/blacklist.d/capi 

   hiermit wird verhindert, dass hotplug den Treiber selbst läd. 

   Das ist wichtig, damit wir die anderen capi-module in einem eigenen 

   script laden können. 

2. /etc/hotplug/usb/capi.usermap

   Hier stehen die USB-IDs drinnen, inkl. dem hotplug-script welches

   ausgeführt werden soll

3. /etc/hotplug/usb/capi

   Das eigentliche Hotplug-Script.

1 und 3 scheinen wohl korrekt zu sein. Bleibt 2. Aber auch da steht es drin.

Sehr merkwürdig. Mach mal bitte ein "capi stop", stell sicher, dass keine CAPI-treiber ö.ä. geladen sind und replugge dann mal die Box. Da müsste dann zumindest mal was von 'capi' etc. auftauchen.

Dass Du für Dich einen workaround gefunden hast (capi.conf) ist zwar schön, mir wäre es aber lieber, wenn auch hotplug funktionieren würde...  :Wink: 

----------

## sbriesen

hmpf! Da hat sich wohl ein bisserl "cut'n'paste" im Beitrag verirrt. :-/

Ich hoffe er ist trotzdem verständlich, ansonsten poste ich es nochmal.

----------

## sprittwicht

Die Botschaft kam trotz cut&paste an.  :Wink: 

Also in den 3 Dateien steht alles drin. Wenn ich capi stoppen will, bleibt das Modul capifs zurück, dass ich auch von Hand nicht entfernen kann weil's wohl noch benutzt wird. Hab capi aus dem default-Runlevel rausgeschmissen und neu gestartet, ohne das Modem.

Wenn ich das Modem dann anschließe, krieg ich nur die Meldung, dass ein USB-Gerät angeschlossen wurde. Weder capi noch der Treiber werden geladen.

Hab ich irgendwas ganz dummes übersehen? Gibt's ähnlich modules-update und env-update noch irgendwas wie conf-update für die Dateien in /etc/conf.d? Die werden doch erst bei Bedarf gelesen, oder nicht?

----------

## sbriesen

nee, da gibts sonst nix.

Mich wundert schlicht, dass das hotplug-script nicht aufgerufen wird. Die USB-Meldung kommt vom USB-Treiber. Der produziert dann daraufhin die hotplug-Messi, welche dann alles andere in Ganz setzt.

SEHR KOMISCH!

----------

## sprittwicht

Rätsel gelöst.

Das hotplug-Script wurde aufgerufen, allerdings ist er in der ersten Zeile des add-Abschnitts gescheitert:

```
/bin/ln 2>/dev/null -s "$$" "${LOCK}" || exit 0
```

Und zwar weil die Lock-Dateien, die er benutzen wollte, schon belegt waren:

```
ls -al /tmp/.capi-usb*

lrwxrwxrwx   1 root   root        4 30. Apr 20:57 .capi-usb-001-002 -> 6784

lrwxrwxrwx   1 root   root        5 30. Apr 19:13 .capi-usb-001-003 -> 10703

lrwxrwxrwx   1 root   root        5 30. Apr 22:45 .capi-usb-001-004 -> 13966

lrwxrwxrwx   1 root   root        5 30. Apr 22:47 .capi-usb-001-005 -> 14049
```

Der 30. April war auch der Schicksalstag, an dem ich Kernel- und capi4k-utils geupgradet habe. Da wird also aus irgendeinem grausamen Grund was hängengeblieben sein. Nachdem ich die Symlinks gelöscht habe kann ich nun auch fröhlich cold- und hotpluggen bis der Arzt kommt.

----------

## sbriesen

ohhhh!!!  :Wink: 

Ich dachte, ich könnte auf eine Überprüfung von Zeitstempeln, etc. verzichten. Locks älter als Uptime sollten sowieso gelöscht werden... *g*

Nichtsdestotrotz habe ich in der aktuellen Version von capi4k-utils das unlock mit einem 'trap' realisiert. Also egal wie das Script wegfliegt, der Symlink sollte garantiert gelöscht werden. Ausser bei Stromausfall und kill -9.  :Wink: 

Aber besser ich baue noch ein Auto-Remove vor das "ln", wenn der lock zu alt ist.

----------

## sbriesen

ok, habe das hotplug-script überarbeitet. Es ist ab sofort im Portage. Also einfach mal sync'en und dann capi4k-utils re-emergen. Dann kommt das neue script mit drauf (ist keine neue Version deswegen).

----------

