Hallo!
Unter Fedora kann ich meine Fritzcard DSL nicht dazu bewegen, längere Zeit fehlerfrei zu laufen. Dauerbetrieb ist nicht möglich, in unregelmäßigen Abständen (mal nach 7 Stunden, mal nach knapp einem Tag) hängt sich das Ding einfach völlig weg, sodaß ein Reboot angesagt ist.
aus /var/log/messages Warning: kfree_skb passed an skb still on a list (from c4ad0726). Mar 13 22:18:10 guru kernel: ------------[ cut here ]------------ Mar 13 22:18:10 guru kernel: kernel BUG at skbuff.c:316! Mar 13 22:18:10 guru kernel: invalid operand: 0000 Mar 13 22:18:10 guru kernel: iptable_mangle ipt_MASQUERADE iptable_nat ipt_TCPMSS ipt_LOG ipt_multiport ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables ppp_synctty ppp_generic Mar 13 22:18:10 guru kernel: CPU: 0 Mar 13 22:18:10 guru kernel: EIP: 0060:[<c01f4b9f>] Tainted: P Mar 13 22:18:10 guru kernel: EFLAGS: 00010082 Mar 13 22:18:10 guru kernel: Mar 13 22:18:10 guru kernel: EIP is at __kfree_skb [kernel] 0x12f (2.4.22-1.2174.nptl) Mar 13 22:18:10 guru kernel: eax: 00000045 ebx: 01022c31 ecx: 00000001 edx: c2758000 Mar 13 22:18:10 guru kernel: esi: 00010001 edi: c4ac2f40 ebp: c2759cec esp: c2759cb4 Mar 13 22:18:10 guru kernel: ds: 0068 es: 0068 ss: 0068 Mar 13 22:18:10 guru kernel: Process fcdsl_thread (pid: 1623, stackpage=c2759000) Mar 13 22:18:10 guru kernel: Stack: c027cc80 c4ad0726 c2615e84 c4ad0726 c1157480 00000202 c2759cec c4ad0677 Mar 13 22:18:10 guru kernel: c3f96000 00000007 c2615364 00000010 c2783004 00000001 c2759d3c c4acf146 Mar 13 22:18:10 guru kernel: c2615364 00000001 00010102 00002c31 c2783004 00000000 c2759d3c c4affc9e Mar 13 22:18:10 guru kernel: Call Trace: [<c4ad0726>] queue_conf [fcdsl] 0xe6 (0xc2759cb8) Mar 13 22:18:10 guru kernel: [<c4ad0726>] queue_conf [fcdsl] 0xe6 (0xc2759cc0) Mar 13 22:18:10 guru kernel: [<c4ad0677>] queue_conf [fcdsl] 0x37 (0xc2759cd0) Mar 13 22:18:10 guru kernel: [<c4acf146>] msg2capi [fcdsl] 0x3a6 (0xc2759cf0) Mar 13 22:18:10 guru kernel: [<c4affc9e>] CAPI_CMSG_2_MESSAGE_INTERNAL [fcdsl] 0x4e (0xc2759d10) Mar 13 22:18:10 guru kernel: [<c4ad9502>] CA_PUT_MESSAGE [fcdsl] 0x12 (0xc2759d40) Mar 13 22:18:10 guru kernel: [<c4ae566f>] CAPI_PUT_CMSG_INTERNAL [fcdsl] 0xf (0xc2759d60) Mar 13 22:18:10 guru kernel: [<c4aedc61>] BHandler [fcdsl] 0x3a1 (0xc2759d80) Mar 13 22:18:10 guru kernel: [<c4b8a3f8>] tx_flag [fcdsl] 0x0 (0xc2759da4) Mar 13 22:18:10 guru kernel: [<c4ace523>] enter_critical [fcdsl] 0x53 (0xc2759dc0) Mar 13 22:18:10 guru kernel: [<c4b67e5f>] .rodata.str1.1 [fcdsl] 0x1049 (0xc2759e88) Mar 13 22:18:10 guru kernel: [<c4ae0b7c>] CAPI_Dequeue32 [fcdsl] 0x1c (0xc2759e90) Mar 13 22:18:10 guru kernel: [<c4b96b40>] _Q_CAPI [fcdsl] 0x0 (0xc2759e94) Mar 13 22:18:10 guru kernel: [<c4aed5fa>] CAPI_Handler [fcdsl] 0x3a (0xc2759eb0) Mar 13 22:18:10 guru kernel: [<c4ae0425>] _CM_Schedule [fcdsl] 0xc5 (0xc2759ee0) Mar 13 22:18:10 guru kernel: [<c4ba1220>] Block_RxBuffer [fcdsl] 0x240 (0xc2759eec) Mar 13 22:18:10 guru kernel: [<c4b96d80>] CMSG.5 [fcdsl] 0x0 (0xc2759ef0) Mar 13 22:18:10 guru kernel: [<c4ace523>] enter_critical [fcdsl] 0x53 (0xc2759f00) Mar 13 22:18:10 guru kernel: [<c4b8a3f8>] tx_flag [fcdsl] 0x0 (0xc2759f04) Mar 13 22:18:10 guru kernel: [<c4ace5b3>] leave_critical [fcdsl] 0x53 (0xc2759f10) Mar 13 22:18:10 guru kernel: [<c4b8a3f8>] tx_flag [fcdsl] 0x0 (0xc2759f14) Mar 13 22:18:10 guru kernel: [<c4ace523>] enter_critical [fcdsl] 0x53 (0xc2759f20) Mar 13 22:18:10 guru kernel: [<c4b8a3f8>] tx_flag [fcdsl] 0x0 (0xc2759f24) Mar 13 22:18:10 guru kernel: [<c4ace5b3>] leave_critical [fcdsl] 0x53 (0xc2759f30) Mar 13 22:18:10 guru kernel: [<c4ad0d35>] os_gettimeofday [fcdsl] 0x15 (0xc2759f40) Mar 13 22:18:10 guru kernel: [<c4ace523>] enter_critical [fcdsl] 0x53 (0xc2759f50) Mar 13 22:18:10 guru kernel: [<c4b8a3f8>] tx_flag [fcdsl] 0x0 (0xc2759f54) Mar 13 22:18:10 guru kernel: [<c4ace5b3>] leave_critical [fcdsl] 0x53 (0xc2759f60) Mar 13 22:18:10 guru kernel: [<c4b8a3f8>] tx_flag [fcdsl] 0x0 (0xc2759f64) Mar 13 22:18:10 guru kernel: [<c4b32e36>] timercb_docallouts [fcdsl] 0x26 (0xc2759f80) Mar 13 22:18:10 guru kernel: [<c4ad9431>] EnterCritical [fcdsl] 0x11 (0xc2759f90) Mar 13 22:18:10 guru kernel: [<c4ad9451>] LeaveCritical [fcdsl] 0x11 (0xc2759fa0) Mar 13 22:18:10 guru kernel: [<c4b05cf9>] B2_PPPoETimerPolling [fcdsl] 0x19 (0xc2759fb0) Mar 13 22:18:10 guru kernel: [<c4ad0cba>] os_timer_poll [fcdsl] 0x5a (0xc2759fb8) Mar 13 22:18:10 guru kernel: [<c4ae053b>] CM_Schedule [fcdsl] 0x3b (0xc2759fd0) Mar 13 22:18:11 guru kernel: [<c4acf3f0>] sched_thread [fcdsl] 0x0 (0xc2759fd8) Mar 13 22:18:11 guru kernel: [<c4acf48f>] sched_thread [fcdsl] 0x9f (0xc2759fe0) Mar 13 22:18:11 guru kernel: [<c01071fd>] kernel_thread_helper [kernel] 0x5 (0xc2759ff0) Mar 13 22:18:11 guru kernel: Mar 13 22:18:11 guru kernel: Mar 13 22:18:11 guru kernel: Code: 0f 0b 3c 01 63 ba 27 c0 58 5a 8b 54 24 08 e9 ce fe ff ff 8d Mar 13 22:18:26 guru pppd[3864]: No response to 3 echo-requests Mar 13 22:18:26 guru pppd[3864]: Serial link appears to be disconnected. Mar 13 22:18:26 guru pppd[3864]: capiplugin: phase terminate (was running). Mar 13 22:18:26 guru pppd[3864]: capiplugin: phase network (was terminate). Mar 13 22:18:26 guru pppd[3864]: capiplugin: phase terminate (was network). Mar 13 22:18:32 guru pppd[3864]: capiplugin: phase dead (was terminate). Mar 13 22:18:42 guru pppd[3864]: capiplugin: disconnectall failed
Hardwarefehler schließe ich aus, der Rechner ist unter Debian Woody schon 2 Wochen am Stück gelaufen, Dail on Demand, Zwangstrennungen etc. kein Problem.
Hat einer eine Idee? Fedora lässt einen da ziemlich im Regen stehen, Bugzilla ist komplett zwecklos, da capi zu den unsupported Modules zählt, siehe: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112605
Hat einer eine Idee?
Christoph
Am Mo, den 22.03.2004 schrieb Christoph Wickert um 23:41:
Hallo!
Unter Fedora kann ich meine Fritzcard DSL nicht dazu bewegen, längere Zeit fehlerfrei zu laufen. Dauerbetrieb ist nicht möglich, in unregelmäßigen Abständen (mal nach 7 Stunden, mal nach knapp einem Tag) hängt sich das Ding einfach völlig weg, sodaß ein Reboot angesagt ist.
aus /var/log/messages
[ schnipp ]
Hardwarefehler schließe ich aus, der Rechner ist unter Debian Woody schon 2 Wochen am Stück gelaufen, Dail on Demand, Zwangstrennungen etc. kein Problem.
Hat einer eine Idee? Fedora lässt einen da ziemlich im Regen stehen, Bugzilla ist komplett zwecklos, da capi zu den unsupported Modules zählt, siehe: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112605
Hat einer eine Idee?
Christoph
Es ist bekannt, dass die Karte bzw. die AVM Treiber instabil sind. Darüber klagen viele Leute, auch Debian als Plattform bildet da keine Ausnahme.
Du kannst dir mal folgende Webseite ansehen:
http://freiburg.linux.de/~zeisberg/howtos/fritzcarddsl.html
Dort gibt es auch einen Patch, der nach Erfahrungsberichten - aus dem ISDN Usenet Forum, von Leuten, die auch den ISDN Teil nutzen - für deutlich bessere Stabilität sorgen soll.
Bei dem von einem Freund eingestellten Bugzilla Artikel geht es um die CAPI policy von Redhat/Fedora. CAPI wird vom Kernel Team weiter gepflegt.
Alexander
Am Di, den 23.03.2004 schrieb Alexander Dalloz
(wer auch sonst, ausdrücklichen Dank auch nochmal wegen neulich -> /etc/sysconfig/i18n :-)) um 00:51:
Am Mo, den 22.03.2004 schrieb Christoph Wickert um 23:41:
Hallo!
Unter Fedora kann ich meine Fritzcard DSL nicht dazu bewegen, längere Zeit fehlerfrei zu laufen. Dauerbetrieb ist nicht möglich, in unregelmäßigen Abständen (mal nach 7 Stunden, mal nach knapp einem Tag) hängt sich das Ding einfach völlig weg, sodaß ein Reboot angesagt ist.
aus /var/log/messages
[ schnipp ]
Hardwarefehler schließe ich aus, der Rechner ist unter Debian Woody schon 2 Wochen am Stück gelaufen, Dail on Demand, Zwangstrennungen etc. kein Problem.
Hat einer eine Idee? Fedora lässt einen da ziemlich im Regen stehen, Bugzilla ist komplett zwecklos, da capi zu den unsupported Modules zählt, siehe: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112605
Hat einer eine Idee?
Christoph
Es ist bekannt, dass die Karte bzw. die AVM Treiber instabil sind. Darüber klagen viele Leute, auch Debian als Plattform bildet da keine Ausnahme.
Wie gesagt, unter Debian läuft der Server hellerbest, was aber jetzt nichts gegen Fedora sagen soll. Unter Debian -> anderer (älterer) Kernel und anderer Treiber-build, kann man also keine Schlüsse draus ziehen.
Du kannst dir mal folgende Webseite ansehen: http://freiburg.linux.de/~zeisberg/howtos/fritzcarddsl.html
Danke, kannte ich schon.
Dort gibt es auch einen Patch, der nach Erfahrungsberichten - aus dem ISDN Usenet Forum, von Leuten, die auch den ISDN Teil nutzen - für deutlich bessere Stabilität sorgen soll.
Danke, auch das hatte ich schon mal gelesen, aber noch nicht angewendet. Seit 12 2 Stunden läuft der Rechner nun mit neuem, gepatchtem Treiber. Und läuft (noch).
Bei dem von einem Freund eingestellten Bugzilla Artikel geht es um die CAPI policy von Redhat/Fedora. CAPI wird vom Kernel Team weiter gepflegt.
Erkläre mir bitte den Unterschied, ich weiß ehrlich gesagt nicht, was CAPI policy sein heissen soll? Dem Ende des Bugzilla Artikels entnehme ich, dass für den 2.4er Kernel keine Anstrengungen mehr unternommen werden, was CAPI betrifft.
Die Unterstützung für AVM Produkte ist aber m. M. n. nicht besonders gut, nicht mal mit normalem Hisax Treiber laufen die Karten out-of-the-box. (Gibt's nen Bugzilla Report zu: Redhat-config-network und usernetctl merken nicht, dass das Device aktiv ist, deaktivieren geht nicht.)
Andererseits kann man das auch AVM in die Schuhe schieben. Deren Support (und wahrscheinlich auch Entwicklung) ist dermaßen SuSE-fixiert: Ruft man das install-Script auf, kommt: "Kein Controller gefunden. Bitte aktivieren sie ihren Fritz Controller in YaST." - Na vielen Dank. Als ich mal eine Support-Anfrage gestellt hatte, kam die Antwort, man könne meinen Fehler nicht reproduzieren, weil man keinen Debian-Rechner habe.
Anyway, mein Rechner läuft jetzt und ich lass ihn jetzt mal testweise gnadenlos an. (http://wickert.dyndns.info/phpsysinfo)
Christoph
Am Di, den 23.03.2004 schrieb Christoph Wickert um 13:59:
Am Di, den 23.03.2004 schrieb Alexander Dalloz
(wer auch sonst, ausdrücklichen Dank auch nochmal wegen neulich -> /etc/sysconfig/i18n :-)) um 00:51:
Och, da nicht für - solange "wer auch sonst" nicht heißen sollte "der Kerl nun schon wieder" :-)
Wie gesagt, unter Debian läuft der Server hellerbest, was aber jetzt nichts gegen Fedora sagen soll. Unter Debian -> anderer (älterer) Kernel und anderer Treiber-build, kann man also keine Schlüsse draus ziehen
[ super, mailman hat beim anderen Posting mal wieder zugeschlagen - darum noch mal, ohne GPG Signatur]
Am Di, den 23.03.2004 schrieb Christoph Wickert um 13:59:
Am Di, den 23.03.2004 schrieb Alexander Dalloz
(wer auch sonst, ausdrücklichen Dank auch nochmal wegen neulich -> /etc/sysconfig/i18n :-)) um 00:51:
Och, da nicht für - solange "wer auch sonst" nicht heißen sollte "der Kerl nun schon wieder" :-)
Wie gesagt, unter Debian läuft der Server hellerbest, was aber jetzt nichts gegen Fedora sagen soll. Unter Debian -> anderer (älterer)
Kernel
und anderer Treiber-build, kann man also keine Schlüsse draus ziehen.
Das ist durchaus interessant, zumal Meldungen über Instabilität auch von Debian Usern kommen. Man müsste sich mal die Arbeit machen und schaun, in welchen Bereichen Debian und Redhat den Kernel gepatcht haben, was CAPI und auch den ppp stack angehen.
Du kannst dir mal folgende Webseite ansehen: http://freiburg.linux.de/~zeisberg/howtos/fritzcarddsl.html
Danke, kannte ich schon.
Schade.
Dort gibt es auch einen Patch, der nach Erfahrungsberichten - aus
dem
ISDN Usenet Forum, von Leuten, die auch den ISDN Teil nutzen - für deutlich bessere Stabilität sorgen soll.
Danke, auch das hatte ich schon mal gelesen, aber noch nicht
angewendet.
Seit 12 2 Stunden läuft der Rechner nun mit neuem, gepatchtem Treiber. Und läuft (noch).
Dann warten wir mal weiter ab.
Bei dem von einem Freund eingestellten Bugzilla Artikel geht es um
die
CAPI policy von Redhat/Fedora. CAPI wird vom Kernel Team weiter gepflegt.
Erkläre mir bitte den Unterschied, ich weiß ehrlich gesagt nicht, was CAPI policy sein heissen soll? Dem Ende des Bugzilla Artikels entnehme ich, dass für den 2.4er Kernel keine Anstrengungen mehr unternommen werden, was CAPI betrifft.
"CAPI policy" ist sicher etwas unglücklich formuliert. Es geht darum, dass Teile des Kernels, wie eben auch CAPI, unsupported sind. Meiner Lesart nach bedeutet das, dass diese Teile im Kernel nicht aktiv von Redhat gepflegt werden, sprich es wird nicht "gebackported" oder sonstwie abweichend vom Vanilla Kernel optimiert. Folglich halten Änderungen und gegebenenfalls Verbesserungen der betroffenen Module erst dann Einzug, wenn auch die Kernel Major Version wechselt.
Die Unterstützung für AVM Produkte ist aber m. M. n. nicht besonders gut, nicht mal mit normalem Hisax Treiber laufen die Karten out-of-the-box. (Gibt's nen Bugzilla Report zu: Redhat-config-network und usernetctl merken nicht, dass das Device aktiv ist, deaktivieren geht nicht.)
Ein Bug ist natürlich Redhat anzulasten oder besser gesagt deren Aufgabe, zu fixen. Was ISDN4Linux im Kernel angeht, lag da lange einiges im Argen. Leider lässt einen die aktuelle Situation mit mISDN in der 2.6er Kernellinie auch nicht grad vor Freude jubilieren. Teilweise funktionieren Karten und Treiber, die unter 2.4.x seit Jahren problemfrei funktionierten, nun nicht mehr.
Andererseits kann man das auch AVM in die Schuhe schieben. Deren
Support
(und wahrscheinlich auch Entwicklung) ist dermaßen SuSE-fixiert: Ruft man das install-Script auf, kommt: "Kein Controller gefunden. Bitte aktivieren sie ihren Fritz Controller in YaST." - Na vielen Dank. Als ich mal eine Support-Anfrage gestellt hatte, kam die Antwort, man
könne
meinen Fehler nicht reproduzieren, weil man keinen Debian-Rechner
habe.
So ganz nachvollziehen kann ich die einseitige Beschränkung von AVM auf SuSE als Linux Plattform auch nicht. Aber SuSE als deutsche - zumindest ehemals deutsche, bis der rote Riese Novell kam ... - Distribution bietet sicher die weitaus beste Integration von ISDN. Wobei dieser Umstand leicht zu erklären ist, da ISDN in Deutschland eine weltweite Sonderstellung einnimmt. Selbst im europäischen Raum ist ISDN nirgends so deckend verbreitet wie hier in Deutschland. Und auch in den USA ist ISDN eher eine unübliche Technik. Deswegen war ISDN auf Redhat auch sehr lange doch eher stiefmütterlich unterstützt. Wenn ich mich da noch an meine Anstrengungen erinnere, seinerzeit meine TELES 16.3c ISDN Karte auf Redhat 5.2 in Betrieb zu nehmen. Leider hatte das Aufgehen von DLD in Redhat damals nicht zu direkt spürbaren Verbesserungen geführt.
Auf der anderen Seite gab es lange Zeit mit den AVM Treibern echte Probleme, die teilweise closed source Treiber auf anderen Systemen als SuSE erfolgreich zu kompilieren und auch zu benutzen. Ich erinnere mich noch gut, wie mich auf Redhat 7.2 das Problem mit dem __udivdi3 unresolved symbol zahllose Nerven gekostet hat. Gleiche Probleme hatten übrigens auch Debian Anwender, es hatte also nichts mit dem seinerzeit eingesetzen gcc Version 2.96 - für den Redhat ja sehr gescholten wurde - zu tun. Inzwischen hat AVM dieses Problem gelöst, trotzdem findet man auf dem FTP Server i.d.R. an Stelle des aktuellen Treiber tarballs oft genug nur ein Textfile mit dem Hinweis, der Treiber finde sich auf der SuSE CD. Eine seltsame, aber ganz offensichtlich bewusste Produktpolitik. Über closed source Treiber brauchen wir hier glaube ich erst gar nicht zu reden.
Anyway, mein Rechner läuft jetzt und ich lass ihn jetzt mal testweise gnadenlos an. (http://wickert.dyndns.info/phpsysinfo)
Bin ich gespannt. Halt uns doch mal auf dem Laufenden.
Christoph
Beste Grüße
Alexander
de-users@lists.fedoraproject.org