System hängt beim Runterfahren wegen '/usr/sbin isdnctrl delif ippp0'
Hallo, beim Runterfahren bleibt mein Server mit SuSE 8.1 öfters bei "Shutting down network interfaces:" hängen. Ich habe herrausgefunden das das Problem beim Stoppen des "SMPPPD" ensteht. Dort wird '/usr/sbin isdnctrl delif ippp0' ausgeführt, dieser Prozess hängt aber und das System bleibt beim Runterfahren hängen. Im Thread "ISDN und kinternet unter SuSE 8.1 = Absturz" gehts vermutlich um den selben Fehler. Ich hatte auf dem Server KDE nur kurz benutzt, dass die Tastatur plötzlich nicht mehr reagierte tratt nachvollziehbar nach ändern der ISDN-Konfiguration in yast auf! Hardware/Software: 1. CPU Type/Takt + Motherboard(Chipsatz) AMD 200MHz 2. RAM Groesse 128MB 3. ISDN HW/Treiber AVM FritzCard ISA non Plug-and-Play 4. kernelversion: uname -a Den Kernel aus: k_deflt-2.4.19-174.i586.rpm 5. rpm -q i4l-base Müsste i4l-base-2003.2.14-1 sein (genaue Infos zu 4.+5. morgen, komm grad nicht an der Server) Gruß Ingo -- 'Linux is like a wigwam: no gates, no windows and an apache inside.'
Am Donnerstag, 27. März 2003 18:43 schrieb Ingo Göppert:
Hallo,
beim Runterfahren bleibt mein Server mit SuSE 8.1 öfters bei "Shutting down network interfaces:" hängen. Ich habe herrausgefunden das das Problem beim Stoppen des "SMPPPD" ensteht. Dort wird '/usr/sbin isdnctrl delif ippp0' ausgeführt, dieser Prozess hängt aber und das System bleibt beim Runterfahren hängen.
Im Thread "ISDN und kinternet unter SuSE 8.1 = Absturz" gehts vermutlich um den selben Fehler. Ich hatte auf dem Server KDE nur kurz benutzt, dass die Tastatur plötzlich nicht mehr reagierte tratt nachvollziehbar nach ändern der ISDN-Konfiguration in yast auf!
Hardware/Software:
1. CPU Type/Takt + Motherboard(Chipsatz) AMD 200MHz
2. RAM Groesse 128MB
3. ISDN HW/Treiber AVM FritzCard ISA non Plug-and-Play
4. kernelversion: uname -a Den Kernel aus: k_deflt-2.4.19-174.i586.rpm
Wieso nicht den k_athlonxxxx? Hier auch den Neuen vom FTP saugen ,der auf der CD ist ziemlich buggy was ISDN betrifft.Vielleicht liegt es schon daran???? Gruß Axel
On Fri, Mar 28, 2003 at 09:03:29AM +0100, Axel Lindlau wrote:
Am Donnerstag, 27. März 2003 18:43 schrieb Ingo Göppert:
Hallo,
beim Runterfahren bleibt mein Server mit SuSE 8.1 öfters bei "Shutting down network interfaces:" hängen. Ich habe herrausgefunden das das Problem beim Stoppen des "SMPPPD" ensteht. Dort wird '/usr/sbin isdnctrl delif ippp0' ausgeführt, dieser Prozess hängt aber und das System bleibt beim Runterfahren hängen.
Im Thread "ISDN und kinternet unter SuSE 8.1 = Absturz" gehts vermutlich um den selben Fehler. Ich hatte auf dem Server KDE nur kurz benutzt, dass die Tastatur plötzlich nicht mehr reagierte tratt nachvollziehbar nach ändern der ISDN-Konfiguration in yast auf!
Hardware/Software:
1. CPU Type/Takt + Motherboard(Chipsatz) AMD 200MHz ^^^^^^
2. RAM Groesse 128MB
3. ISDN HW/Treiber AVM FritzCard ISA non Plug-and-Play
4. kernelversion: uname -a Den Kernel aus: k_deflt-2.4.19-174.i586.rpm
Wieso nicht den k_athlonxxxx?
Weil es nach den Daten kein Athlon sondern ein aelterer AMD ist.
Hier auch den Neuen vom FTP saugen ,der auf der CD ist ziemlich buggy was ISDN betrifft.Vielleicht liegt es schon daran????
Nein, die Probleme treten erst mit dem Updatekernel auf. Ich bin am debuggen. -- Karsten Keil SuSE Labs ISDN development
Hallo, hier noch die Ausgabe von uname -a: Linux mailserver 2.4.19-4GB #1 Wed Nov 27 00:56:40 UTC 2002 i586 unknown und rpm -q i4l-base: i4l-base-2003.2.14-1 Karsten Keil schrieb: [..]
Nein, die Probleme treten erst mit dem Updatekernel auf. Ich bin am debuggen.
Wo wird dann das Bugfix veröffentlich? Krieg ich das nur auf dieser Liste mit? Gruß Ingo
On Fri, Mar 28, 2003 at 01:11:39PM +0100, Ingo Göppert wrote:
Hallo,
hier noch die Ausgabe von uname -a: Linux mailserver 2.4.19-4GB #1 Wed Nov 27 00:56:40 UTC 2002 i586 unknown
und rpm -q i4l-base: i4l-base-2003.2.14-1
Karsten Keil schrieb: [..]
Nein, die Probleme treten erst mit dem Updatekernel auf. Ich bin am debuggen.
Wo wird dann das Bugfix veröffentlich? Krieg ich das nur auf dieser Liste mit?
Das weiss ich erst wenn der BUG gefunden ist und es einen Fix gibt. Zumindest wird es hier die ersten Fixes/workarounds geben. -- Karsten Keil SuSE Labs ISDN development
On Fri, Mar 28, 2003 at 02:08:47PM +0100, Karsten Keil wrote:
On Fri, Mar 28, 2003 at 01:11:39PM +0100, Ingo Göppert wrote:
Hallo,
hier noch die Ausgabe von uname -a: Linux mailserver 2.4.19-4GB #1 Wed Nov 27 00:56:40 UTC 2002 i586 unknown
und rpm -q i4l-base: i4l-base-2003.2.14-1
Karsten Keil schrieb: [..]
Nein, die Probleme treten erst mit dem Updatekernel auf. Ich bin am debuggen.
Wo wird dann das Bugfix veröffentlich? Krieg ich das nur auf dieser Liste mit?
Das weiss ich erst wenn der BUG gefunden ist und es einen Fix gibt. Zumindest wird es hier die ersten Fixes/workarounds geben.
Leider weigert sich der Bug sich zu offfenbaren, das einzigste was ich haerausfinden konnte ist, das es irgendwo am locking der netlink devices zu einem race kommt. Dummerweise zeigt ein diff zwischen dem 8.1 orginal kernel und dem update kernel keine Aenderungen in diesem Bereich. Da die Benachrichtigung der netlink Devices ueber das Herunterfahren einer dynamischen Addresse dabei eine Rolle zu spielen scheint, kann der Effekt eventuell durch Abschalten dieses Mechanismus vermieden werden. In /etc/sysconfig/network/scripts/ifup-ippp die Zeile ip link set $DEVICE dynamic on auskommentieren und die ippp devices neu starten. Bitte mal testen, das ist auch ein Hinweis ob die bisherigen Ergebnisse von mir richtig interpretiert wurden. -- Karsten Keil SuSE Labs ISDN development
Hallo, Karsten Keil schrieb am 01.04.2003 09:37: [...]
Leider weigert sich der Bug sich zu offfenbaren, das einzigste was ich haerausfinden konnte ist, das es irgendwo am locking der netlink devices zu einem race kommt. Dummerweise zeigt ein diff zwischen dem 8.1 orginal kernel und dem update kernel keine Aenderungen in diesem Bereich. Wo liegt der Unterschied zwischen dem Kernel von der CD und dem gepachten? Kann ich nicht einfach wieder den von der CD installieren und dann bin ich die Probleme los oder ist das nicht zu empfehlen?
Da die Benachrichtigung der netlink Devices ueber das Herunterfahren einer dynamischen Addresse dabei eine Rolle zu spielen scheint, kann der Effekt eventuell durch Abschalten dieses Mechanismus vermieden werden.
In /etc/sysconfig/network/scripts/ifup-ippp die Zeile
ip link set $DEVICE dynamic on
auskommentieren und die ippp devices neu starten.
Hab ich gemacht, hat leider nix gebracht. nach 2x Runterfahren hing die Kiste wieder. Ich habe dann mal die unbenutzte Soundkarte ausgebaut, LPT und PS2-Maus im BIOS abgeschaltet und zumindest bis jetzt (5x Neustart) funktioniert alles einwandfrei.
Bitte mal testen, das ist auch ein Hinweis ob die bisherigen Ergebnisse von mir richtig interpretiert wurden.
Zumindest hat sich meiner Ansicht nach durch das Auskommentieren nix verbessert :-( Gruß Ingo PS: Ein angehender Datentechniker fragt sich: Was ist ein "race"? Wenn sich das in wenigen Worten erklären lässt... -- 'Linux is like a wigwam: no gates, no windows and an apache inside.'
On Tue, Apr 01, 2003 at 07:20:26PM +0200, Ingo Göppert wrote:
Hallo,
Karsten Keil schrieb am 01.04.2003 09:37: [...]
Leider weigert sich der Bug sich zu offfenbaren, das einzigste was ich haerausfinden konnte ist, das es irgendwo am locking der netlink devices zu einem race kommt. Dummerweise zeigt ein diff zwischen dem 8.1 orginal kernel und dem update kernel keine Aenderungen in diesem Bereich. Wo liegt der Unterschied zwischen dem Kernel von der CD und dem gepachten? Kann ich nicht einfach wieder den von der CD installieren und dann bin ich die Probleme los oder ist das nicht zu empfehlen?
Da die Benachrichtigung der netlink Devices ueber das Herunterfahren einer dynamischen Addresse dabei eine Rolle zu spielen scheint, kann der Effekt eventuell durch Abschalten dieses Mechanismus vermieden werden.
In /etc/sysconfig/network/scripts/ifup-ippp die Zeile
ip link set $DEVICE dynamic on
auskommentieren und die ippp devices neu starten.
Hab ich gemacht, hat leider nix gebracht. nach 2x Runterfahren hing die Kiste wieder.
Das hat mich erstmal wieder auf eine falsche Faehrte gebracht, letzendlich hing es doch damit zusammen, nur konnte "dynamic off" das Problem nicht verhindern (s.u). OK der Bug ist jetzt gefunden, leider ist ein Fix nicht so einfach möglich. Der Fehler ist schon immer latent im code vorhanden, warum es mit dem Update Kernel akut wird weiss ich nicht, wahrscheinlich liegt es an irgentwelchen Aenderungen im Scheduler. Ich habe aber erstmal ein hoffentlich wirsames workaround: In /etc/sysconfig/network/scripts/ifup-ippp am Ende der down) Section kurz vor status) steht die Zeile mit dem $SBIN/isdnctrl delif $DEVICE ... ip link set dev $DEVICE down $SBIN/isdnctrl delif $DEVICE >& /dev/null retcode=$? ;; status) ... Dort sollte ein sleep eingebaut werden, das dafuer sorgt das isdnctrl delif erst gestartet wird, wenn alle anderen Sachen, insbesondere die durch das Auflegen getrigerten, fertig sind. Also z.B. ... ip link set dev $DEVICE down # give the $DEVICE time to do all hangup work before deleting it sleep 5 $SBIN/isdnctrl delif $DEVICE >& /dev/null retcode=$? ;; status) ... Die 5 sec sind ein willkürlicher Wert, wenn es damit gut klappt, kann man versuchen den Wert zu verkleinern. Stoeren sollte das nicht, aufgelegt wird sofort beim Klick auf kinternet nur die naechste Anwahl ist erst nach diesem zusaetzlichen delay moeglich und das Runterfahren des Systems dauert entsprechend laenger. DialOnDemand ist vom Fehler garnicht betroffen.
Ich habe dann mal die unbenutzte Soundkarte ausgebaut, LPT und PS2-Maus im BIOS abgeschaltet und zumindest bis jetzt (5x Neustart) funktioniert alles einwandfrei.
Das ist mehr oder weniger Zufall, dadurch hat sich das Fenster in dem der Race zuschlagen kann nur entsprechend postiv verschoben, unter anderen Lastbedingungen kann es wieder auftreten.
Bitte mal testen, das ist auch ein Hinweis ob die bisherigen Ergebnisse von mir richtig interpretiert wurden.
Zumindest hat sich meiner Ansicht nach durch das Auskommentieren nix verbessert :-(
Ja, da hatte ich etwas uebersehen.
PS: Ein angehender Datentechniker fragt sich: Was ist ein "race"? Wenn sich das in wenigen Worten erklären lässt...
race := Wettrennen Gut hier die Erklaerung was passiert: Wenn eine ISDN Verbindung getrennt wird, wird an alle Netzwerkkomponenten ein Event geschickt (NETDEV_REBOOT) das diese darueber informiert. Da hierfür verkettete Listen abgearbeitet werden, muessen solche Events serialisiert werden und den Readlock fuer diese Listen besitzen (damit nicht ein anderer Prozess die Liste waehrend der Abarbeitung veraendern kann). Da ein Hangup auch aus den Interrupt Kontext (Gegenstelle legt auf) kommen kann und man im Interrupt auf einen solchen lock nicht warten kann, wird das nicht direkt gemacht, sondern ein Event, das ueber den keventd (prozess 2 in ps -ax) im usercontext(nicht interrupt context) abgearbeitet wird, gequeued. Wann dieses Event abgearbeitet wird haengt davon ab, wieviele events dort schon anstehen und was sonst noch so im system los ist. Da nach jedem event erstmal andere Prozesse eine Chance bekommen, passiert folgendes: Bei Auflegen einer nich DoD Verbindung mit kinternet wird das interface komplett ueber den Aufruf von ifdown ippp0 runtergefahren. Wenn es nun passiert das zum Zeitpunkt wo isdnctrl delif ippp0 anlaeuft das Event noch nicht abgearbeitet wurde, bekommt der isdnctrl delif prozess das lock, so das wenn das Event jetzt an die Reihe kommt es auf diesen lock warten muss, normalerweise kein problem, aber wenn keventd wartet, werden auch keine anderen events mehr ausgeführt und da scheinbar die Tastatur ueber keventd laeuft, koennen waehrend dieser Zeit keine Tastenevents weitergeleitet werden (das ist der Grund warum das System nicht mehr zu reagieren scheint, Mouseevents werden offensichtlich anders verarbeitet). Das Ganze stellt aber noch kein Problem dar, da ja eigentlich der isdnctrl delif Prozess irgendwann fertig sein sollte und den lock freigibt. Denkste! In den meisten Faellen passiert folgendes: unregister_netdevice verteilt u.a. ein hotplug event ueber den start von /sbin/hotplug und der Start von /sbin/hotplug erfolgt ueber keventd -> keventd wartet aber ---> DEAD LOCK. Aber selbst wenn durch das timing dieser Prozess noch gestartet wurde spaetesten an Ende von unregister_netdevice ist eine Scheife die wartet darauf, das es keine Referenzen mehr auf dieses device gibt (weil sonst auf Ressourcen zugegriffen werden wuerde die schon freigegeben sind). Bei der Generierung des NETDEV_REBOOT events wurde eine solche Referenz angelegt ---> Endlos Loop (allerdings noch mit funktionierender Tastaur). Da das alles im core network code passiert (nicht im ISDN code) ist vmlinuz betroffen und es wird ein komplettes Kernelupdate benötigt. Aber der Fix ist auch nicht so einfach ohne neue Races zu erzeugen, die locks sind leider nicht umsonst vorhanden und nirgends ueberfluessig. -- Karsten Keil SuSE Labs ISDN development
Am Dienstag, 15. April 2003 10:24 schrieb Karsten Keil:
On Tue, Apr 01, 2003 at 07:20:26PM +0200, Ingo Göppert wrote:
Hallo,
Karsten Keil schrieb am 01.04.2003 09:37: [...]
Leider weigert sich der Bug sich zu offfenbaren, das einzigste was ich haerausfinden konnte ist, das es irgendwo am locking der netlink devices zu einem race kommt. Dummerweise zeigt ein diff zwischen dem 8.1 orginal kernel und dem update kernel keine Aenderungen in diesem Bereich.
Ich habe aber erstmal ein hoffentlich wirsames workaround:
In /etc/sysconfig/network/scripts/ifup-ippp am Ende der down) Section kurz vor status) steht die Zeile mit dem $SBIN/isdnctrl delif $DEVICE ... ip link set dev $DEVICE down $SBIN/isdnctrl delif $DEVICE >& /dev/null retcode=$? ;; status) ...
Dort sollte ein sleep eingebaut werden, das dafuer sorgt das isdnctrl delif erst gestartet wird, wenn alle anderen Sachen, insbesondere die durch das Auflegen getrigerten, fertig sind. Also z.B. ... ip link set dev $DEVICE down # give the $DEVICE time to do all hangup work before deleting it sleep 5 $SBIN/isdnctrl delif $DEVICE >& /dev/null retcode=$? ;; status) ...
Die 5 sec sind ein willkürlicher Wert, wenn es damit gut klappt, kann man versuchen den Wert zu verkleinern. Stoeren sollte das nicht, aufgelegt wird sofort beim Klick auf kinternet nur die naechste Anwahl ist erst nach diesem zusaetzlichen delay moeglich und das Runterfahren des Systems dauert entsprechend laenger. DialOnDemand ist vom Fehler garnicht betroffen.
Hallo Karsten,
sorry, aber dein Workaround scheint nicht zu funktionieren. Wenn ich das genau
so übernehme, wie du es beschreibst, kann ich mich genau einmal via kinternet
ins Netz einwählen. Der zweite und jeder weitere Verbindungsaufbau scheitert.
Erst nach einem "rcsmpppd restart" funktioniert es wieder genau einmal.
Es wird auch eine Fehlermeldung in der /var/log/messages ausgegeben, die kann
ich aber jetzt leider nicht hier einfügen, da ich gerade am anderen Rechner
sitze. Sorry, vielleicht heute abend. Trotzdem, vielleicht bin ich ja nicht
der einzige, bei dem dieses seltsame Verhalten zu Tage tritt.
Wenn ich die Zeile sleep 5 dann auskommentiere, funktioniert's wieder
problemlos.
Gruß
Tim
--
Tim Fischer
On Wed, Apr 16, 2003 at 12:49:29PM +0200, Tim Fischer wrote:
Am Dienstag, 15. April 2003 10:24 schrieb Karsten Keil:
On Tue, Apr 01, 2003 at 07:20:26PM +0200, Ingo Göppert wrote:
Hallo,
Karsten Keil schrieb am 01.04.2003 09:37: [...]
Leider weigert sich der Bug sich zu offfenbaren, das einzigste was ich haerausfinden konnte ist, das es irgendwo am locking der netlink devices zu einem race kommt. Dummerweise zeigt ein diff zwischen dem 8.1 orginal kernel und dem update kernel keine Aenderungen in diesem Bereich.
Ich habe aber erstmal ein hoffentlich wirsames workaround:
In /etc/sysconfig/network/scripts/ifup-ippp am Ende der down) Section kurz vor status) steht die Zeile mit dem $SBIN/isdnctrl delif $DEVICE ... ip link set dev $DEVICE down $SBIN/isdnctrl delif $DEVICE >& /dev/null retcode=$? ;; status) ...
Dort sollte ein sleep eingebaut werden, das dafuer sorgt das isdnctrl delif erst gestartet wird, wenn alle anderen Sachen, insbesondere die durch das Auflegen getrigerten, fertig sind. Also z.B. ... ip link set dev $DEVICE down # give the $DEVICE time to do all hangup work before deleting it sleep 5 $SBIN/isdnctrl delif $DEVICE >& /dev/null retcode=$? ;; status) ...
Die 5 sec sind ein willkürlicher Wert, wenn es damit gut klappt, kann man versuchen den Wert zu verkleinern. Stoeren sollte das nicht, aufgelegt wird sofort beim Klick auf kinternet nur die naechste Anwahl ist erst nach diesem zusaetzlichen delay moeglich und das Runterfahren des Systems dauert entsprechend laenger. DialOnDemand ist vom Fehler garnicht betroffen.
Hallo Karsten, sorry, aber dein Workaround scheint nicht zu funktionieren. Wenn ich das genau so übernehme, wie du es beschreibst, kann ich mich genau einmal via kinternet ins Netz einwählen. Der zweite und jeder weitere Verbindungsaufbau scheitert. Erst nach einem "rcsmpppd restart" funktioniert es wieder genau einmal. Es wird auch eine Fehlermeldung in der /var/log/messages ausgegeben, die kann ich aber jetzt leider nicht hier einfügen, da ich gerade am anderen Rechner sitze. Sorry, vielleicht heute abend. Trotzdem, vielleicht bin ich ja nicht der einzige, bei dem dieses seltsame Verhalten zu Tage tritt. Wenn ich die Zeile sleep 5 dann auskommentiere, funktioniert's wieder problemlos.
Also ich habe den workaround bei mir mit verschiedenen Werten von 5 sec - 50 sec getestet, nie gab es ein Problem, jedesmal nach dem das Icon wieder ready zeigte, konnte ich die Anwahl starten. (Manual Setup, nicht DOD) -- Karsten Keil SuSE Labs ISDN development
Hallo Karsten, sorry, aber dein Workaround scheint nicht zu funktionieren. Wenn ich das genau so übernehme, wie du es beschreibst, kann ich mich genau einmal via kinternet ins Netz einwählen. Der zweite und jeder weitere Verbindungsaufbau scheitert. Erst nach einem "rcsmpppd restart" funktioniert es wieder genau einmal. Es wird auch eine Fehlermeldung in der /var/log/messages ausgegeben, die kann ich aber jetzt leider nicht hier einfügen, da ich gerade am anderen Rechner sitze. Sorry, vielleicht heute abend. Trotzdem, vielleicht bin ich ja nicht der einzige, bei dem dieses seltsame Verhalten zu Tage tritt. Wenn ich die Zeile sleep 5 dann auskommentiere, funktioniert's wieder problemlos.
Also ich habe den workaround bei mir mit verschiedenen Werten von 5 sec - 50 sec getestet, nie gab es ein Problem, jedesmal nach dem das Icon wieder ready zeigte, konnte ich die Anwahl starten. (Manual Setup, nicht DOD)
-- Karsten Keil SuSE Labs ISDN development
Hallo Karsten,
wie gesagt, ich bekomme einmal eine Verbindung ins Internet hergestellt. Beim
zweiten Mal meldet der Kernel ( auf Konsole 10 bzw. in /var/log/messages):
Apr 16 18:57:21 pc2 kernel: isdn_ppp_bind: Can't find a (free) connection to
the ipppd daemon.
Auch bei jedem weiteren Versuch erscheint die Meldung. Wie gesagt, nach einem
Neustart des smpppd funktioniert's wieder genau einmal. Das ganze läßt sich
problemlos und beliebig reproduzieren.
Auch wenn ich z.B. ein "sleep 2" einsetze, passiert es, nur wenn ich die Zeile
auskommentiere, ist auch ein zweiter Verbindungsaufbau möglich.
Das Verhalten von kinternet läßt mich darauf schließen, daß ich mich nicht
vertippt habe, wenn ich "sleep 5" eingebe, dauert es ca. 5 sec., bis
kinternet wieder "Ready" anzeigt.
Wobei das nicht heißt, daß ich deinen Workaround nicht nachvollziehen kann.
Gruß
Tim
--
Tim Fischer
On Wed, Apr 16, 2003 at 07:08:13PM +0200, Tim Fischer wrote:
Hallo Karsten, sorry, aber dein Workaround scheint nicht zu funktionieren. Wenn ich das genau so übernehme, wie du es beschreibst, kann ich mich genau einmal via kinternet ins Netz einwählen. Der zweite und jeder weitere Verbindungsaufbau scheitert. Erst nach einem "rcsmpppd restart" funktioniert es wieder genau einmal. Es wird auch eine Fehlermeldung in der /var/log/messages ausgegeben, die kann ich aber jetzt leider nicht hier einfügen, da ich gerade am anderen Rechner sitze. Sorry, vielleicht heute abend. Trotzdem, vielleicht bin ich ja nicht der einzige, bei dem dieses seltsame Verhalten zu Tage tritt. Wenn ich die Zeile sleep 5 dann auskommentiere, funktioniert's wieder problemlos.
Also ich habe den workaround bei mir mit verschiedenen Werten von 5 sec - 50 sec getestet, nie gab es ein Problem, jedesmal nach dem das Icon wieder ready zeigte, konnte ich die Anwahl starten. (Manual Setup, nicht DOD)
-- Karsten Keil SuSE Labs ISDN development
Hallo Karsten, wie gesagt, ich bekomme einmal eine Verbindung ins Internet hergestellt. Beim zweiten Mal meldet der Kernel ( auf Konsole 10 bzw. in /var/log/messages):
Apr 16 18:57:21 pc2 kernel: isdn_ppp_bind: Can't find a (free) connection to the ipppd daemon.
Das heist das das device geup'ed wird bevor der ipppd laeuft. Was das mit einem delay vor dem Runterfahren zu tun haben soll ist mir raetselhaft.
Auch bei jedem weiteren Versuch erscheint die Meldung. Wie gesagt, nach einem Neustart des smpppd funktioniert's wieder genau einmal. Das ganze läßt sich problemlos und beliebig reproduzieren.
Hast Du mehrere ippp's definiert ? Laueft der smpppd noch nach dem Auflegen ? (ps -ax |grep smpppd) -- Karsten Keil SuSE Labs ISDN development
Am Donnerstag, 17. April 2003 00:27 schrieb Karsten Keil:
On Wed, Apr 16, 2003 at 07:08:13PM +0200, Tim Fischer wrote:
Hallo Karsten, sorry, aber dein Workaround scheint nicht zu funktionieren. Wenn ich das genau so übernehme, wie du es beschreibst, kann ich mich genau einmal via kinternet ins Netz einwählen. Der zweite und jeder weitere Verbindungsaufbau scheitert. Erst nach einem "rcsmpppd restart" funktioniert es wieder genau einmal. Es wird auch eine Fehlermeldung in der /var/log/messages ausgegeben, die kann ich aber jetzt leider nicht hier einfügen, da ich gerade am anderen Rechner sitze. Sorry, vielleicht heute abend. Trotzdem, vielleicht bin ich ja nicht der einzige, bei dem dieses seltsame Verhalten zu Tage tritt. Wenn ich die Zeile sleep 5 dann auskommentiere, funktioniert's wieder problemlos.
Also ich habe den workaround bei mir mit verschiedenen Werten von 5 sec - 50 sec getestet, nie gab es ein Problem, jedesmal nach dem das Icon wieder ready zeigte, konnte ich die Anwahl starten. (Manual Setup, nicht DOD)
-- Karsten Keil SuSE Labs ISDN development
Hallo Karsten, wie gesagt, ich bekomme einmal eine Verbindung ins Internet hergestellt. Beim zweiten Mal meldet der Kernel ( auf Konsole 10 bzw. in /var/log/messages):
Apr 16 18:57:21 pc2 kernel: isdn_ppp_bind: Can't find a (free) connection to the ipppd daemon.
Hallo Karsten, hallo Tim, exakt das gleiche Verhalten hier. Auch dir Meldung in /var/log/messages ist identisch!
Das heist das das device geup'ed wird bevor der ipppd laeuft. Was das mit einem delay vor dem Runterfahren zu tun haben soll ist mir raetselhaft.
Mir auch
Auch bei jedem weiteren Versuch erscheint die Meldung. Wie gesagt, nach einem Neustart des smpppd funktioniert's wieder genau einmal. Das ganze läßt sich problemlos und beliebig reproduzieren.
Hier auch!
Hast Du mehrere ippp's definiert ? Laueft der smpppd noch nach dem Auflegen ? (ps -ax |grep smpppd)
Der smpppd läuft weiter. Ich habe nur ein ippp0 eingerichtet - allerdings mit mehreren Providern. Beim Einstellen eines neuen Providers ist die Einwahl sofort wieder erfolgreich möglich. Der dazugehörige Eintrag in /var/log/messages lautet: Apr 17 05:52:36 tux /etc/hotplug/net.agent[9651]: Setting up NET devices switched of. Exiting net.agent ... Grüße Herbert -- The primary requisite for any new tax law is for it to exempt enough voters to win the next election.
Hallo Herbert, hallo *, Herbert Renkewitz schrieb am 17.04.2003 05:54:
Am Donnerstag, 17. April 2003 00:27 schrieb Karsten Keil:
On Wed, Apr 16, 2003 at 07:08:13PM +0200, Tim Fischer wrote:
Hallo Karsten, sorry, aber dein Workaround scheint nicht zu funktionieren. Wenn ich das genau so übernehme, wie du es beschreibst, kann ich mich genau einmal via kinternet ins Netz einwählen. Der zweite und jeder weitere Verbindungsaufbau scheitert. Erst nach einem "rcsmpppd restart" funktioniert es wieder genau einmal. Es wird auch eine Fehlermeldung in der /var/log/messages ausgegeben, die kann ich aber jetzt leider nicht hier einfügen, da ich gerade am anderen Rechner sitze. Sorry, vielleicht heute abend. Trotzdem, vielleicht bin ich ja nicht der einzige, bei dem dieses seltsame Verhalten zu Tage tritt. Wenn ich die Zeile sleep 5 dann auskommentiere, funktioniert's wieder problemlos.
Also ich habe den workaround bei mir mit verschiedenen Werten von 5 sec - 50 sec getestet, nie gab es ein Problem, jedesmal nach dem das Icon wieder ready zeigte, konnte ich die Anwahl starten. (Manual Setup, nicht DOD)
-- Karsten Keil SuSE Labs ISDN development
Hallo Karsten, wie gesagt, ich bekomme einmal eine Verbindung ins Internet hergestellt. Beim zweiten Mal meldet der Kernel ( auf Konsole 10 bzw. in /var/log/messages):
Apr 16 18:57:21 pc2 kernel: isdn_ppp_bind: Can't find a (free) connection to the ipppd daemon.
Hallo Karsten, hallo Tim,
exakt das gleiche Verhalten hier. Auch dir Meldung in /var/log/messages ist identisch!
Das heist das das device geup'ed wird bevor der ipppd laeuft. Was das mit einem delay vor dem Runterfahren zu tun haben soll ist mir raetselhaft.
Mir auch
Auch bei jedem weiteren Versuch erscheint die Meldung. Wie gesagt, nach einem Neustart des smpppd funktioniert's wieder genau einmal. Das ganze läßt sich problemlos und beliebig reproduzieren.
Hier auch!
Hast Du mehrere ippp's definiert ? Laueft der smpppd noch nach dem Auflegen ? (ps -ax |grep smpppd)
Der smpppd läuft weiter. Ich habe nur ein ippp0 eingerichtet - allerdings mit mehreren Providern. Beim Einstellen eines neuen Providers ist die Einwahl sofort wieder erfolgreich möglich. Der dazugehörige Eintrag in /var/log/messages lautet: Apr 17 05:52:36 tux /etc/hotplug/net.agent[9651]: Setting up NET devices switched of. Exiting net.agent ... Bei welche Providern tritt das Problem auf? Bei mir nur bei t-online(by call). Nutze ich aber so selten dass mir erst heute aufgefallen ist.
Gruß Ingo
On Thu, Apr 17, 2003 at 05:54:46AM +0200, Herbert Renkewitz wrote:
Hallo Karsten, hallo Tim,
exakt das gleiche Verhalten hier. Auch dir Meldung in /var/log/messages ist identisch!
Das heist das das device geup'ed wird bevor der ipppd laeuft. Was das mit einem delay vor dem Runterfahren zu tun haben soll ist mir raetselhaft.
Mir auch
Auch bei jedem weiteren Versuch erscheint die Meldung. Wie gesagt, nach einem Neustart des smpppd funktioniert's wieder genau einmal. Das ganze läßt sich problemlos und beliebig reproduzieren.
Hier auch!
Hast Du mehrere ippp's definiert ? Laueft der smpppd noch nach dem Auflegen ? (ps -ax |grep smpppd)
Der smpppd läuft weiter. Ich habe nur ein ippp0 eingerichtet - allerdings mit mehreren Providern. Beim Einstellen eines neuen Providers ist die Einwahl sofort wieder erfolgreich möglich. Der dazugehörige Eintrag in /var/log/messages lautet: Apr 17 05:52:36 tux /etc/hotplug/net.agent[9651]: Setting up NET devices switched of. Exiting net.agent ...
OK um weitere Vergleiche machen zu koennen: SuSE Version (8.X) Das /etc/sysconfig/network/scripts/ifup-ipppd mit dem delay /etc/sysconfig/network/ifcfg-ippp0 und das Provider File (User und passwort durch dummys ersetzen. Desweiteren: /etc/smpppd*.conf /var/lib/smpppd/* Bitte als Mail direkt an mich, nicht an die Liste. -- Karsten Keil SuSE Labs ISDN development
Hallo Karsten, Karsten Keil schrieb am 15.04.2003 10:24:
In /etc/sysconfig/network/scripts/ifup-ippp die Zeile
ip link set $DEVICE dynamic on
auskommentieren und die ippp devices neu starten.
Ich habe aber erstmal ein hoffentlich wirsames workaround:
In /etc/sysconfig/network/scripts/ifup-ippp am Ende der down) Section kurz vor status) steht die Zeile mit dem $SBIN/isdnctrl delif $DEVICE ... ip link set dev $DEVICE down $SBIN/isdnctrl delif $DEVICE >& /dev/null retcode=$? ;; status) ...
Dort sollte ein sleep eingebaut werden, das dafuer sorgt das isdnctrl delif erst gestartet wird, wenn alle anderen Sachen, insbesondere die durch das Auflegen getrigerten, fertig sind. Also z.B. ... ip link set dev $DEVICE down # give the $DEVICE time to do all hangup work before deleting it sleep 5 $SBIN/isdnctrl delif $DEVICE >& /dev/null retcode=$? ;; status) ...
Die 5 sec sind ein willkürlicher Wert, wenn es damit gut klappt, kann man versuchen den Wert zu verkleinern. Stoeren sollte das nicht, aufgelegt wird sofort beim Klick auf kinternet nur die naechste Anwahl ist erst nach diesem zusaetzlichen delay moeglich und das Runterfahren des Systems dauert entsprechend laenger. DialOnDemand ist vom Fehler garnicht betroffen. Der Rechner lässt sich (bis jetzt) einwandfrei runterfahren. Die 5 sec. fallen nicht ins Gewicht und ich werde sie beibehalten. Was mitr aufgefallen ist dass in der boot.omsg jetzt folgendes auftaucht: <notice>/etc/init.d/rc3.d/K07smpppd stop Shutting down SMPPPD<notice>killproc: kill(523,15) <notice>killproc: kill(523,9)
done
<notice>'/etc/init.d/rc3.d/K07smpppd stop' exits with status 0
Bisher war es so dass immer wenn dieses "killXXX" 2 mal (1x "15", 1x "9") erschien der PC danach hängenblieb. Jetzt scheint das die Regel zu sein, das Hangenbleiben scheint aber behoben :-) Die Probleme von Tim treten bei meinem Desktop-PC (Fritzcard PCI2, 1,2 GHz Athlon, 786MB RAM, Kernel 2.4.19-4GB #1 Wed Dec 11 12:03:23 PST 2002 i686 unknown) nicht auf, nur sind in diesem Fall 5 sec ein bischen lang... Ich hatte allerdings vor Änderungen an der ifup-ippp auch keine Probleme mit der Tastatur und die Änderungen nur zum Testen auch bei mir durchgeführt. Gruß Ingo -- 'Linux is like a wigwam: no gates, no windows and an apache inside.'
participants (5)
-
Axel Lindlau -
Herbert Renkewitz -
Ingo Göppert -
Karsten Keil -
Tim Fischer