PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : CAPI4Linux mit Fritz!PCI bringt Server zum Absturz


Julian
10.08.01, 08:18
Hallo,

seit langem benutze ich die CAPI4Linux von AVM erfolgreich. Ich kompiliere diese inzwischen selbst und bin auch mit der eigentlichen Funktion sehr zufrieden. Meine kompilierten und leicht angepassten Versionen stelle ich anderen unter http://doc.thepenguin.de/capi4linux/
zur Verfügung.

Leider musste ich in letzter Zeit einen enormen Anstieg an Instabilität meines Systems feststellen. So hängt sich der Server von Zeit zu Zeit in unregelmäßigen Abständen - meist mindestens einmal am Tag - einfach auf. Es steht nichts in /var/log/messages. Nach dem harten Neustart findet sich dort nur eine Zeitlücke, in der nichts aufgezeichnet wurde (das System stand demnach). Heute war es zum Beispiel so, dass ich das erst heute Früh bemerkt habe, der Server jedoch seit 05:24:12 keine Logeinträge mehr hat. Der letzte Logeintrag sieht auch demnach unspektakulär aus:

Aug 10 05:24:12 station isdnlog: Aug 10 05:24:12 tei 71 calling T-Online with Computer Telekom/01033

Darunter befindet sich noch eine Zeile, die nur aus Punkten besteht (Ansicht mit mcedit). Vermutlich ESC-Steuerzeichen oder so. Haben da ja eigentlich nichts zu suchen.

Tja, wie komme ich darauf, dass das ganze mit der CAPI4Linux zu tun hat? Ich habe mittlerweile hier für kurze Zeit zwei Server mit nahezu identischer Konfiguration stehen. Das Phänomen tritt bei beiden auf - jedoch nur bei dem sehr häufig, der die Internet-Verbindung bereitstellt. Ich habe da mittlerweile von dem einen auf den anderen Server umgestellt. Siehe da: Der vorherige Server stürzt nicht mehr ab - dafür jetzt der Neue. Im "Alten" steckt eine Fritz!PCI, im Neuen eine Fritz!CLASSIC.

Vielleicht noch etwas über meine Konfiguration und meine Vorgehensweise: Auf beiden Servern ist SuSE Linux 7.2 in einer recht schlank gehaltenen Installation drauf. Als Kernel setze ich 2.4.7-4GB (von
ftp.suse.com/pub/people/mantel/) ein. Hat damit aber nichts zu tun, da ich vorher ebenso auch den 2.4.6-4GB, 2.4.5-4GB, und 2.4.4-4GB hatte. Für den 2.4.4-4GB hatte ich mir damals auch selbst ein Modul kompiliert. Wenn ich da die Größe meines Moduls mit dem mittlerweile von AVM für 2.4.4-4GB vergleiche, stelle ich einen Größenunterschied fest. Folglich macht AVM etwas anders beim Kompilieren für seine Module. Beim Kompilieren bin ich immer auf den Fehler gestoßen, dass version.h nicht mehr vorhanden ist und dass ich es nur von /boot nach /usr/src/linux/include/linux/ kopieren müsse, es aber eine schlechte Art wäre, es zu verwenden, da es wohl mittlerweile überholt sei. Dann fehlte noch die /usr/src/linux/include/modversions.h, welche ich einfach von einem älteren Kernel dorthin kopiert habe (sie enthält sowieso nur einen Hinweis auf modsetver.h). Danach kompiliert sich die CAPI ohne Probleme. Das Modul lässt sich laden und funktioniert scheinbar auch. Als laufende Dienste habe ich: capidrv als Bridge für i4l (vielleicht liegts auch hierdran? AVM liefer da nochmals RPMs mit, die c4l-lib und c4l-sys enthalten - brauche ich das unbedingt? Wofür?), capi4hylafax, mtGCAPRI Server (ein Server, der die CAPI dem Netzwerk zur Verfügung stellt). Die Internet-Einwahl erfolgt per ISDN DialOnDemand und besteht tagsüber beinahe durchgehend.

So, etwas viel, aber andere hängen dafür meterweise Logs an, die einem nichts sagen ;-) Wäre schön, wenn mir jemand helfen könnte!

LKH
10.08.01, 15:37
Hallo,

wir setzen auch euer Tool für den 2.4.4er Kernel ein. Der Faxserver (AMD K6-2/400, 128 MB, SuSE 7.2, Fritz!PCI) läuft seit dem Update auf dei 7.2 24 Stunden am Tag und es gibt überhaupt keine Probleme.

Leider bin ich ein völlig unbegnadeter Programmierer und habe daher auch wenig Kompiliererfahrung. Ich wollte nur sagen, dass deine Version in dieser Umgebung problemlos läuft.

Julian
10.08.01, 15:52
Danke für den Hinweis - hört man gern ;-)

Wie sich herausstellte, lag das ganze auch nicht an der CAPI, sondern an einem Fehler im aktuellen 2.4er Kernel. Dieser liegt beim Masquerading mit iptables ab Version 2.4.3/4 vor und wurde erst in 2.4.7acX bzw. 2.4.8preX behoben. Nach Installation des neuen Kernels inklusive Patch funktioniert es wohl wieder. Aber wie lange und stabil, wird die Zeit zeigen ;-)