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