watchdog timeout – resetting

Ne0n

Ne0n

professional newbie
Tach zusammen.

Muss mich mal wieder zu Wort melden :rolleyes:

Ein Server spinnt ein wenig rum:
"bge1: watchdog timeout – resetting" erscheint auf der Konsole. Anschließend kein Netzwerk mehr, kein Rebbot Möglich.
In den Logs ist nichts zu finden.

Mein erster Versuch war die andere Onboard Karte des HP-Servers zu verwenden (vorher bge0) - wie die Meldung schon sagt leider ohne Erfolg.
Habe dann meinen Freund google gefragt aber keine verbindlichen Aussagen gefunden...

Könnte eine PCI Karte (Intel) Abhilfe schaffen?
Gibt es einen anderen Weg?

Wäre fein wenn jemand etwas dazu sagen kann.
 
Ohne APCI... Manchmal sieht man den Wald vor lauter Bäumen nicht. Danke, das werde ich testen.

FreeBSD ist in Version 5.4. Also nicht die aktuellste.
Würde ich auch solange dabei belassen, bis mir jemand definitiv sagt das ein Update Besserung bringt.

Verkabelung ist in Ordnung.
Hardwarefehler kann ich nicht ausschließen, weshalb sich mir ja auch die Idee mit der Intel Netzwerkkarte aufdrängte.

Leider tritt der Fehler - ich liebe sowas :mad: - nur sporadisch auf.
Ich teste also einmal einen Intel NIC und APCI.

Gruß & Schönes Wochenende,
Ne0n
 
Bei meinen letzten Server war der IDA Kabel kaputt ich habe erst bemerkt als ihn in einem anderen Komputer einbauen wollte.
Bei mir war das hatte keinen Netz mehr, deshlab prüfe deinen Kabel ob die nicht defekt sind.
 
Ich wärm diesen Thread mal auf...

Habe dasselbe Problem auf nem ThinkPad R51e mit FreeBSD 6.2-PRERELEASE.
Wenn ich ohne ACPI boote geht es ohne timeout, aber ich empfinde das nicht als Lösung. Hängt es vielleicht mit shared interrupts zusammen?

Bei mir liegt bge0 zusammen mit cbb0 auf IRQ11. Kann man das irgendwie umgehen?

Gruß
Enrico
 
Interessant finde ich, dass es auch bei dir eine Broadcom Karte ist, die den Fehler produziert.
Ich kann leider noch nicht sagen ob es an der Karte (bzw. dem Treiber) liegt, da wir noch nicht umgesteckt haben (bei dem Server kann ich allerdings auch auf ACPI verzichten).

Ich befürchte die IRQ Vergabe kannst man beim ThinkPad auch nicht so variieren wie man es gern hätte.

Haben andere Releases von freeBSD den Fehler auch schon produziert, oder tritt es erst auf seitdem du 6.2 verwendest?
 
Ne0n schrieb:
Interessant finde ich, dass es auch bei dir eine Broadcom Karte ist, die den Fehler produziert.
Ich kann leider noch nicht sagen ob es an der Karte (bzw. dem Treiber) liegt, da wir
Zum Vergrößern anklicken....
Ich spekuliere stark auf Treiber und/oder Zusammenspiel mit anderen Treibern, da unter Linux die Karte auch unter Vollast ohne Probleme läuft.

Ich werde mal versuchen, das Ganze ohne den CardBus-Treiber(brauch ich im Moment nicht) laufen zu lassen. Mal sehen, ob es was ändert.

Ne0n schrieb:
Haben andere Releases von freeBSD den Fehler auch schon produziert, oder tritt es erst auf seitdem du 6.2 verwendest?
Zum Vergrößern anklicken....
Nein, liegt aber daran, dass 6.2 das erste BSD ist, was auf dem Gerät läuft ;-).
Bin BSD-Newbie, komme aus der bösen Linux-Welt *g*.
 
Zuletzt bearbeitet:
deadeye schrieb:
Habe dasselbe Problem auf nem ThinkPad R51e mit FreeBSD 6.2-PRERELEASE.
Wenn ich ohne ACPI boote geht es ohne timeout, aber ich empfinde das nicht als Lösung. Hängt es vielleicht mit shared interrupts zusammen?

Bei mir liegt bge0 zusammen mit cbb0 auf IRQ11. Kann man das irgendwie umgehen?
Zum Vergrößern anklicken....
Das ist vielleicht auch ne Meldung auf stable@ wert ;) Dort finden sich im Archiv auch zuhauf Mails zu dem Thema...

HTH,
Philipp
 
Also hab meinen Kernel neu kompiliert, diesmal ohne den Cardbus-Treiber und nun teilt sich die Netzwerkkarte bge0 den IRQ 11 mit der WLan-Karte ath0.

Unter Linux kann man eine Kernel-Option aktivieren, womit es nicht nur die üblichen 15 IRQs gibt, sondern weit mehr, bis zu 30. So lassen sich so Doppelbelegungen verhindern. Weiß leider nicht mehr, wie die Option hieß.
Gibt es vielleicht sowas auch unter FreeBSD?

Ich hab mir ma obigen Link mit den Posts auf stable@ angeschaut, aber ne Lösung hab ich da auch nicht gefunden ;-(.
 
Ich glaube, ich habe mein Problem gelöst, bin mir nur nicht sicher wie gut ;-).

Habe mal hint.apic.0.disabled="1" in die loader.conf geschrieben und seitdem scheint es zu gehen, grade recht viel die Karte beansprucht über längere Zeit und sie lief. Sonst ist sie immer nach den ersten paar Paketen schon ausgestiegen.

Gerade nochmal verifiziert und den Eintrag auskommentiert und voila, ich bekomm den timeout.

Jetzt ist die Frage: welche Nebenwirkungen hat das Deaktivieren von APIC?
 
Moin!

Ich habe neuerdings das gleiche Problem: xl0 watchdog timeout.

NIC und Netzwerkkabel sind ohne Probleme seit Tagen in/an einem anderen Rechner gelaufen. Die einzige Änderung ist ein Dual-P3 Board gegenüber single-Athlon bzw. single-P3 Boards, die vorher die Karte aufgenommen haben.

Ich glaube nicht recht an einen Defekt der NIC-Karte, kann es evtl. mit dem SMP-Kernel zusammenhängen?

Dank Euch!
Axel
 
Hi,
xl0 watchdog timeout
stellt bei mir kein Problem dar, es funktioniert alles wie zuvor. Ich glaube damit sagt er nur dass irgendein Puffer voll ist. Bin mir aber nicht mehr sicher.

Mfg Legorado
 
Ein Watchdog Timeout bedeutet immer, dass irgendetwas nicht mehr reagiert hat und resetet wurde (normalerweise Hardware).
 
Wenn das beim Überfliegen der Sourcen richtig sehe, dann wird diese Watchdog-Fehlermeldung hauptsächlich in xl_txeoc() ausgeloest.
Das ist der End-Of-Channel-Interrupt-Handler, welcher (u.A.) direkt die Register der Netzwerkkarte ausliest und auswertet um auch nach dem Wohlbefinden der Netzwerkkarte zu fragen.
Die Ursache liegt demnach in einem Fehlerzustand der Netzwerkkarte, d.h. sie glaubt, dass irgendwas ihr entgangen sei.

In den letzten Commits in src/sys/pci/if_xl.c spielt das Timeout jedenfalls immer eine Rolle, da irgendwelche Races geschehen können.

Wenn ich die Kommentare in den Commits richtig verstehe, dann bezwecken diese Races eine Fehlinterpretation des Netzwerkkartenzustandes und es wird fälschlicher Weise in den Fehlerzustand gesprungen.
Leider führt das nicht nur zu dieser Fehlermeldung sondern auch zu einem Reset der Karte, was wiederum zu verlorenen Frames führen kann.

Ist auf der betroffenen Kiste vielleicht eine andere Version von FreeBSD?
Aber es wird wahrscheinlich eher an den mehreren CPUs liegen, da dies wegen echter Parallelität Races bevorzugt anlocken.

Ich wuerde man die letzte Version des if_xl versuchen:
/usr/src/sys/pci/if_xl.c
/usr/src/sys/pci/if_xlreg.h

Gruss
Markus
 
Um es mal (zumindest halbwegs) abzuschließen:
Ohne APCI läuft es nun schon seit mehreren Wochen stabil (danke FierceOne). Die neuen if_xl hab ich nicht versucht, wollte keine weiteren Experimente auf dem Server veranstalten; Danke trotzdem für den Hinweis, hilft bestimmt auch anderen, falls es in den neuen Versionen noch akkut ist.

Gruß,
Ne0n
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben