4:41 p.m.
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
5:51 p.m.
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
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 1 (Yarrow) on Athlon CPU kernel 2.4.22-1.2174.nptl
Sirendipity 00:40:57 up 3 days, 9:23, load average: 0.44, 0.16, 0.11
[ Γνωθι σ'αυτον - gnothi seauton ]
my life is a planetarium - and you are the stars
6:59 a.m.
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
2:59 p.m.
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
3:17 p.m.
[ 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
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 1 (Yarrow) on Athlon CPU kernel 2.4.22-1.2174.nptl
Sirendipity 22:16:03 up 4 days, 6:58, load average: 0.10, 0.06, 0.07
[ Γνωθι σ'αυτον - gnothi seauton ]
my life is a planetarium - and you are the stars
7331
days inactive
7332
days old
de-users@lists.fedoraproject.org
4 comments
2 participants
participants (2)
-
Alexander Dalloz -
Christoph Wickert