System hängt beim Runterfahren wegen '/usr/sbin isdnctrl delif ippp0' ... gelöst?
Hallo, gibt es mittlerweile eine Lösung für das Problem? Der Thread dazu begann am 27.03. Bei mir tritt selbiges auch auf, 'sleep 5' verhindert zwar, dass das System hängt, nach jedem Verbindungsabbau muss ich aber den ipppd neustarten (siehe auch die Mail von Tim Fischer, 16.04.2003 19:08). Ich nutze übrigens auch T-Online!? System: Pentium 150, 32 MB RAM Elsa ML PCF-Pro k_deflt-2.4.19-174 i4l-base-2003.2.14-1 i4l-isdnlog-2002.11.5-0 Danke, Sven
Am Montag, 12. Mai 2003 13:58 schrieb Sven Niese:
Hallo,
gibt es mittlerweile eine Lösung für das Problem? Der Thread dazu begann am 27.03. Bei mir tritt selbiges auch auf, 'sleep 5' verhindert zwar, dass das System hängt, nach jedem Verbindungsabbau muss ich aber den ipppd neustarten (siehe auch die Mail von Tim Fischer, 16.04.2003 19:08). Ich nutze übrigens auch T-Online!? So viel ich weiß, arbeitet Karsten an dem Problem. Eine Lösung ist mr bis jetzt nicht bekannt, scheint wohl wirklich nicht einfach zu sein. Momentan lebe ich halt mit dem Problem und nehme in Kauf, von Zeit zu Zeit die Reset-Taste am Rechner zu betätigen ( die ich sonst bei Linux doch recht selten brauche ). Liegt es eigentlich wirklich an T-Online, daß der Workaround von Karsten (sleep 5 ) nicht funktioniert ? Ich kann mir das fast nicht vorstellen ... Obwohl ich den Workaround mit "sleep 5" rausgenommen habe, passiert es mir nämlich jetzt von Zeit zu Zeit, daß ich ebenfalls den ipppd bzw. smpppd neu starten muß, um mich wieder einwählen zu können. Warum denn das ?
Gruß
Tim
P.S.: Ist ja nett, daß sich jemand an eine meiner Mails erinnert, das passiert
mir sonst so selten ... ;-)
--
Tim Fischer
Hallo Tim,
Liegt es eigentlich wirklich an T-Online, daß der Workaround von Karsten (sleep 5 ) nicht funktioniert ? Ich kann mir das fast nicht vorstellen ... Obwohl ich den Workaround mit "sleep 5" rausgenommen habe, passiert es mir nämlich jetzt von Zeit zu Zeit, daß ich ebenfalls den ipppd bzw. smpppd neu starten muß, um mich wieder einwählen zu können. Warum denn das ?
Ohne "sleep 5" hängt sich das System meistens auf, manchmal aber auch nicht. Mit "sleep 5" läuft das System stabil, vor einer Wiederanwahl muss ich aber den ipppd neustarten: "rcnetwork restart ippp0" Was mir noch aufgefallen ist: ohne den sleep-Befehl in der down(!) - Sektion beendete sich "cinternet --start" manchmal nicht von selbst, entweder ist das Programm erst nach einem "cinternet --stop" fertig oder auch garnicht -> kill... Nach der Änderung mit sleep lief alles wie gewohnt, cinternet blieb nicht hängen - komisch. Was hat aber --start mit der down-Sektion zu tun? Ab morgen geht bei mir hoffentlich wieder DSL, das Modem war beim letzten Gewitter in Mitleidenschaft gezogen worden... Danke für deine Antwort, wenn ich noch etwas helfen kann, stehe ich gern zur Verfügung. Sven
On Mon, May 12, 2003 at 01:58:21PM +0200, Sven Niese wrote:
Hallo,
gibt es mittlerweile eine Lösung für das Problem? Der Thread dazu begann am 27.03. Bei mir tritt selbiges auch auf, 'sleep 5' verhindert zwar, dass das System hängt, nach jedem Verbindungsabbau muss ich aber den ipppd neustarten (siehe auch die Mail von Tim Fischer, 16.04.2003 19:08). Ich nutze übrigens auch T-Online!?
System: Pentium 150, 32 MB RAM Elsa ML PCF-Pro k_deflt-2.4.19-174 i4l-base-2003.2.14-1 i4l-isdnlog-2002.11.5-0
OK, es gibt einen workaround (sleep zwischen auflegen und interface abbauen), der aber scheinbar manchmal andere Probleme triggert (ipppd laeuft weiter). Der endgültige Fix ist nur im kernel möglich, der Patch ist hier: diff -ur linux-2.4.20.SuSE.org/net/core/dev.c linux-2.4.20.SuSE/net/core/dev.c --- linux-2.4.20.SuSE.org/net/core/dev.c 2003-03-17 16:51:15.000000000 +0100 +++ linux-2.4.20.SuSE/net/core/dev.c 2003-04-29 19:00:22.000000000 +0200 @@ -620,16 +620,61 @@ struct dev_tq { struct tq_struct tq; + struct timer_list timer; struct net_device *dev; int event; -}; +}; + +static char *NetEvtStr[16] = { + "0000", + "up", + "down", + "reboot", + "change", + "register", + "unregister", + "change mtu", + "change addr", + "going down", + "change name", + "000B", + "000C", + "000D", + "000E", + "000F" +}; + +static void netdev_event_timer_callback(unsigned long data) +{ + struct dev_tq *tq = (struct dev_tq *) data; + + if (schedule_task(&tq->tq) == 0) { + printk(KERN_WARNING "%s: task for event %s scheduled with delay\n", + __FUNCTION__, NetEvtStr[0xf & tq->event]); + tq->timer.expires = jiffies + 1; + add_timer(&tq->timer); + } +} static void netdev_event_callback(void *data) { - struct dev_tq *tq = (struct dev_tq *) data; - rtnl_shlock(); - notifier_call_chain(&netdev_chain, tq->event, tq->dev); - rtnl_shunlock(); + struct dev_tq *tq = (struct dev_tq *) data; + + if (0 == rtnl_shlock_nowait()) { + notifier_call_chain(&netdev_chain, tq->event, tq->dev); + rtnl_shunlock(); + } else { + if (tq->dev->deadbeaf) { + printk(KERN_WARNING "%s: task for event %s canceled for device shutdown\n", + __FUNCTION__, NetEvtStr[0xf & tq->event]); + } else { + tq->timer.function = netdev_event_timer_callback; + tq->timer.data = (unsigned long)tq; + tq->timer.expires = jiffies + 1; + add_timer(&tq->timer); + return; + } + } dev_put(tq->dev); kfree(tq); } @@ -656,9 +701,12 @@ tq->tq.routine = netdev_event_callback; tq->tq.data = tq; if (schedule_task(&tq->tq) == 0) { - printk(KERN_WARNING __FUNCTION__ - ": task for event %x not scheduled\n", event); - dev_put(dev); + printk(KERN_WARNING "%s: task for event %s scheduled with delay\n", + __FUNCTION__, NetEvtStr[0xf & tq->event]); + tq->timer.function = netdev_event_timer_callback; + tq->timer.data = (unsigned long)tq; + tq->timer.expires = jiffies + 1; + add_timer(&tq->timer); } } -- Karsten Keil SuSE Labs ISDN development
Am Dienstag, 13. Mai 2003 16:36 schrieb Karsten Keil:
OK, es gibt einen workaround (sleep zwischen auflegen und interface abbauen), der aber scheinbar manchmal andere Probleme triggert (ipppd laeuft weiter).
Hallo Karsten,
herzlichen Dank für den Patch (programmieren sollte man können (hihi)). Wird
es in den nächsten Tagen einen offiziellen Updatekernel von SuSE geben, oder
muß ich das Teil selbst kompilieren ? Das dauert halt bei meiner Uraltkiste
Tage ;-). Ist dieser Patch Bestandteil des Kernels oder eines Moduls, dann
könnte ich ja vielleicht nur das entsprechende Modul neu bauen, oder ?
Gruß
Tim
--
Tim Fischer
participants (3)
-
Karsten Keil -
Sven Niese -
Tim Fischer