Fritz-Karte wird beim booten alle 20 Male nicht richtig initialisiert
Hallo, habe Suse 9.2 auf Servern mit dem eigentlich ganz tollen Mainboard ASUS A7N8x-E Deluxe. Bei zwei Kunden habe ich das PRoblem, daß gelegentlich (alle 2-3 Wochen einmal, jeden morgen wird frisch gebootet) die ISDN-KArte (Fritz PCI) beim booten nicht richtig initialisiert wird. Die ISDN-Karte meldet sich dann gar nicht auf dem ISDN-BUS, bekommt auch nichts mit. Das haben wir über den ADSL-ZUgang festgestellt. Wird nach einem ifdown aller ipppX ein rcisdn restart gemacht, dann wird wieder ordnungsgemäß am BUS gelauscht, und nach einem ifup der ipppX funktionierten auch wieder dieselben. Wenn die KArte einmal läuft, dann läuft die, das Probl. besteht nur gelegentlich nach einem reboot.Jmd eine Idee? Hardwareprobleme? In dmesg oder beim booten siehe alles normal aus: alles in grün "done". In /var/log/messages keine Meldungen. isdnctrl status all meldet alle in Ordnung - ist es aber nicht. Also: die Software meldet okay, aber es geht nix durch. Habe dieses Phänomen nur bei dem Deluxe-Board von ASUS, bei Vorgänger- Boards (Abit) hatte ich dieses Phänomen noch nie. Eigentlich ist das Phänomen bei einem Kunden mit dem Deluxe Board verschwunden, beim anderen gibt es das noch. Das Mainboard ist übrigens letzte Woche ausgetauscht worden, weil das GBit-NIC defekt war (Ohhh ASUS, ich dachte das wäre Qualität). Am Mainboard liegt es bestimmt nicht. Hat die Fritz-Karte vielleicht einen Schuss? Wähle ich von hier die KArte an, dann erhalte ich die Meldung No user responding (Private network serving remote user) also so wie wenn der PC abgeschaltet wäre. Beim Versuch vom Server aus zu wählen meint /var/log/messages nur: May 10 10:28:23 pserver kernel: ippp2: dialing 1 00721234567890.. May 10 10:28:32 pserver kernel: isdn_net: local hangup ippp2 danke schon mal Ekkard
Ich würd das rebooten nur auf Kernelupdates und Notfälle beschränken... --> Ansonsten könnt man auch Windows benutzen Wenn das bei jedem 20. Neustart vorkommt, bist du zumindest mal die nächsten 5 Jahre sicher ;-) Könntest aber mal die Reihenfolge prüfen, in der deine Scripte geladen werden --> Vielleicht reichts ja einfach das laden deiner isdn-Treiber 5 sekunden sleepen zu lassen --> Das würd ich jetzt versuchen... Oder ich würd versuchen ob ich den Fehler absichtlich auftreten lassen kann... Interessant wäre auch, in Erfahrung zu bringen was die kiste beim booten so von sich gibt, wenn der fehler auftritt... Ekkard Gerlach <suse-isdn@aiai.de> schrieb am 10.05.2006 15:53:11:
Hallo,
habe Suse 9.2 auf Servern mit dem eigentlich ganz tollen Mainboard ASUS A7N8x-E Deluxe. Bei zwei Kunden habe ich das PRoblem, daß gelegentlich (alle 2-3 Wochen einmal, jeden morgen wird frisch gebootet) die ISDN-KArte (Fritz PCI) beim booten nicht richtig initialisiert wird. Die ISDN-Karte meldet sich dann gar nicht auf dem ISDN-BUS, bekommt auch nichts mit. Das haben wir über den ADSL-ZUgang festgestellt. Wird nach einem ifdown aller ipppX ein rcisdn restart gemacht, dann wird wieder ordnungsgemäß am BUS gelauscht, und nach einem ifup der ipppX funktionierten auch wieder dieselben. Wenn die KArte einmal läuft, dann läuft die, das Probl. besteht nur gelegentlich nach einem reboot.Jmd eine Idee? Hardwareprobleme?
In dmesg oder beim booten siehe alles normal aus: alles in grün "done". In /var/log/messages keine Meldungen. isdnctrl status all meldet alle in Ordnung - ist es aber nicht. Also: die Software meldet okay, aber es geht nix durch.
Habe dieses Phänomen nur bei dem Deluxe-Board von ASUS, bei Vorgänger- Boards (Abit) hatte ich dieses Phänomen noch nie. Eigentlich ist das Phänomen bei einem Kunden mit dem Deluxe Board verschwunden, beim anderen gibt es das noch. Das Mainboard ist übrigens letzte Woche ausgetauscht worden, weil das GBit-NIC defekt war (Ohhh ASUS, ich dachte das wäre Qualität). Am Mainboard liegt es bestimmt nicht. Hat die Fritz-Karte vielleicht einen Schuss?
Wähle ich von hier die KArte an, dann erhalte ich die Meldung No user responding (Private network serving remote user) also so wie wenn der PC abgeschaltet wäre. Beim Versuch vom Server aus zu wählen meint /var/log/messages nur:
May 10 10:28:23 pserver kernel: ippp2: dialing 1 00721234567890.. May 10 10:28:32 pserver kernel: isdn_net: local hangup ippp2
danke schon mal Ekkard
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-isdn-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-isdn-help@suse.com
* Krause_Stephan@gmx.de schrieb:
Ich würd das rebooten nur auf Kernelupdates und Notfälle beschränken... --> Ansonsten könnt man auch Windows benutzen Ja, leider geht das nicht überall. Bei diesem Kunden erzeugt Samba bei gleichzeitigem Zugriff einer alten Win95-Maschine schreibend auf den Server und einem Drucken eines WinXP unter VMware einen smb-Leichen-Prozess, die den Server CPU zu 100% auslastet. Dieser Zombi (oder was auch immer) läßt sich auch mit kill -9 nicht abschießen, es muß smb restart-et werden, dann brechen die Verbindungen von dem Win95-PC ab und schon ist in der Praxis ein EEG und Arbeit von 5-30 Minuten futsch. LÖsung hier: kill -SIGSTOP automatisch von einem intelligenten Skript und jede Nacht reboot, damit die Leichen mit "T" im Prozesslisting mal wieder aufgeräumt werden. Dieser Bug von Samba ist unbekannt (habe keine Antworten in der samba-NG erhalten) und wenn ich solche Kleiigkeiten arkriebisch verfolgen würde, würde ich bis an mein Lebensende keinen Euro verdienen, daher: jede Nacht reboot.
Wenn das bei jedem 20. Neustart vorkommt, bist du zumindest mal die nächsten 5 Jahre sicher ;-)
Könntest aber mal die Reihenfolge prüfen, in der deine Scripte geladen werden --> Vielleicht reichts ja einfach das laden deiner isdn-Treiber 5 sekunden sleepen zu lassen --> Das würd ich jetzt versuchen... Oder ich
gute Idee, danke! Ich könnte das rc-Skript überhaupt auch an das Ende aller Skripten stellen.
würd versuchen ob ich den Fehler absichtlich auftreten lassen kann... Interessant wäre auch, in Erfahrung zu bringen was die kiste beim booten so von sich gibt, wenn der fehler auftritt... Ich war auch schon mal vor Ort. Ich erinnere mich auch an Fehler (rot-Meldungen) meist war aber alles Grün.
danke Gruss Ekkard
Ekkard Gerlach <suse-isdn@aiai.de> schrieb am 11.05.2006 09:33:50:
* Krause_Stephan@gmx.de schrieb:
Ich würd das rebooten nur auf Kernelupdates und Notfälle beschränken... --> Ansonsten könnt man auch Windows benutzen Ja, leider geht das nicht überall. Bei diesem Kunden erzeugt Samba bei gleichzeitigem Zugriff einer alten Win95-Maschine schreibend auf den Server und einem Drucken eines WinXP unter VMware einen smb-Leichen- Prozess, die den Server CPU zu 100% auslastet. Dieser Zombi (oder was auch immer) läßt sich auch mit kill -9 nicht abschießen, es muß smb restart-et werden, dann brechen die Verbindungen von dem Win95-PC ab und schon ist in der Praxis ein EEG und Arbeit von 5-30 Minuten futsch. LÖsung hier: kill-SIGSTOP automatisch von einem intelligenten Skript und jede Nacht reboot, damit die Leichen mit "T" im Prozesslisting mal wieder aufgeräumt werden. Dieser Bug von Samba ist unbekannt (habe keine Antworten in der samba-NG erhalten) und wenn ich solche Kleiigkeiten arkriebisch verfolgen würde, würde ich bis an mein Lebensende keinen Euro verdienen, daher: jede Nacht reboot.
Was mir noch eingefallen ist, zum thema reboot - bzw hardware reset.. klingt jetzt vielleicht etwas komisch, aber würde denn der fehler auftreten wenn du statts nem reboot den rechner ausschaltest und wieder anschaltest..? Sonst könntest ja statt nem "init 6" nen geplanten init 0 machen und damit die kiste ganz abschalten, und im bios nen wake-up timer setzen, der das ganze ding nach 5 minuten wieder startet...
Wenn das bei jedem 20. Neustart vorkommt, bist du zumindest mal die nächsten 5 Jahre sicher ;-)
Könntest aber mal die Reihenfolge prüfen, in der deine Scripte geladen
werden --> Vielleicht reichts ja einfach das laden deiner isdn-Treiber 5 sekunden sleepen zu lassen --> Das würd ich jetzt versuchen... Oder ich
gute Idee, danke! Ich könnte das rc-Skript überhaupt auch an das Ende aller Skripten stellen.
würd versuchen ob ich den Fehler absichtlich auftreten lassen kann... Interessant wäre auch, in Erfahrung zu bringen was die kiste beim booten so von sich gibt, wenn der fehler auftritt... Ich war auch schon mal vor Ort. Ich erinnere mich auch an Fehler (rot-Meldungen) meist war aber alles Grün.
Das wird bei mir nach /var/log/boot.msg geschrieben (ist glaub ich bei suse schon seit eh und jeh ne defaultsache)
danke Gruss Ekkard
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-isdn-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-isdn-help@suse.com
participants (2)
-
Ekkard Gerlach -
Krause_Stephan＠gmx.de