Netzwerkfehler, bei hoher CPU-Last

troll

Well-Known Member
Ich bin ratlos.

Mein neuer Desktop ist da - zumindest teilweise, der Intel NIC fehlt noch.
On Board ist ein Marvelnic.
Zu den bekannten watchdog timeouts des Marvels kam ein ganz anderes Problem:

Wenn ich Daten per scp kopieren bricht die Performance nach einiger Zeit ein, wenn ich *eine* CPU(von 4 Kenren) belaste. Das geht hin bis zu timeouts, tcpdump zeigt, dass viele Pakete doppelt gesendet werden, also anscheinend nicht ankommen. ping hat ca. 10% packet loss.

OK, ich hab ne Realtec aus meiner Grabbelkiste eingebaut, die zwar wirklich Mist ist, aber solche Probleme definitiv nicht hatte. Die Marvel hab ich im BIOS deaktiviert und zusätzlich sogar noch nen Kern ohne msk gebaut.

Mit der rl passiert das Selbe.

Was könnte hier los sein?
Netzwerkkabel, switch, etc ist getestet. Die Fehler treten auch auf, wenn ich ne andere Maschine abklemme, die das Prob nicht hat und daran den neuen Desk hänge.
 
Ich hab den Transfer nach einem Neustart der Kiste neu angestupst. Nach 24GB Transfer sehe ich das hier:
Code:
Mem: 26M Active, 3481M Inact, 286M Wired, 138M Cache, 214M Buf, 7804K Free
Swap: 32G Total, 16K Used, 32G Free

Die Kiste swapt....
 
Wo soll da was swappen?

Und: Was treibt die Gegenstelle? Ist da alles in Ordnung?
 
16k used. Zwar minimal...
Gegenstelle ist in Ordnung. Von der Gegenstelle aus auf andere Kisten klappt alles. Wie geschrieben auch, wenn ich den Problembär an die Leitung einer funktionierenden Gegenstelle hänge.

Ich fahr die Kiste grad heiss und reboote direkt in memtest+
Ich tippe auf Speicher, oder im Extremfall auf Mainboard...
 
Die 16k oder was da auch immer im kB-Bereich dransteht habe ich schon auf verschiedensten Systemen beobachtet...und bei keinem dieser Systeme kann von der Anwendung und der Last überhaupt der Grund aufgetreten sein auch nur irgendetwas in den Swap verlagern zu müssen. Was da genau passiert, kann ich auch nicht genau sagen...aber ein "normales" swappen ist es nicht.

Fehlersuche würde ich jetzt auch Richtung Speicher/Mainboard schieben.
 
Das mit den 16k geht schon noch hoch. Zwar nicht wesendlich, aber immerhin, auf 100 kommt es. Mal abwarten, was der Speichertest sagt. scp nimmt sich ja beim Kopieren nen ordendlichen Schluck aus der Pulle, wodurch dann auch der Speicher wärmer wird.
Das ist übrigens Corsair 2GB Twin-Speicher mit Kühlung drauf...
 
Prozesse die über 24 Stunden nicht benutzt werden landen im Swap. Das könnte der Grund sein, da würde ich also nicht nach einem Fehler suchen.
 
Prozesse die über 24 Stunden nicht benutzt werden landen im Swap. Das könnte der Grund sein, da würde ich also nicht nach einem Fehler suchen.

So lange lief die Kiste bisher noch nicht stabil.
Das passiert nach ca. 1/2Std. kopieren und zwar ca. gleichzeitig mit dem Performanceeinbruch. Die Kiste hatte ungefähr die selbe uptime - ungefähr ne halbe Stunde.
Ich tippe inzwischen auf ne RAM-Inkompatibilität.
Der Corsair-Speicher, der verbaut ist, ist als kompatibel aufgeführt, mit ner Restriktion, dass man ihn auf 800er runtertakten soll, wenn man mehr als eine Bank benutzt. Ist zwischenzeitlich auch noch niedriger getaktet gewesen.

Es gibt ein BIOS-Update, dass eine Speicherkompatibilität beheben soll, dass ich aber nicht einspielen werde, da ich damit rechne das Board reklamieren zu müssen.
Vorgehensweise ist jetzt die, das ein anderer Speicher ausprobiert wird, der auch als kompatibel gilt und mehr Wald und Wiesen Speicher ist. Wenn die Probleme damit immer noch bestehen geht das Board zurück.
 
Derartige Speicherprobleme mit Corsair kann ich bestätigen. Hatte ich als ich mein aktuelles System gebaut habe ebenfalls und ein kumpel von mir der damals Zeitgleich ein neues System aufgezogen hat konnte das verhalten auch nachvollziehen. Wir haben angenommen dass da ein Fehler in der Serie war, aber dem scheint wohl nicht so.
Ich habe es danach mal mit OCZ probiert, wovon ich nur sagen kann, dass die bei mir ohne Mucken laufen. Er hat zu Transcend gegriffen, was ich jetzt auch im Laptop verbaut habe. Rennen we ne 1.
 
hmm, keine probleme hier und bei nem anderen desktop ebenfalls nicht mit corsair speichern. selbst im mischbetrieb mit anderen riegeln laufen sie fehlerfrei
 
Ich tippe wie gesägt inzwischen nicht mehr auf einen Speicherfehler, sondern wenn überhaupt auf eine Inkompatibilität. Das Verhalten tritt ja nur im Zusammenhang mit dem Netzwerk auf.

Inzwischen habe ich noch etwas anderes gefunden. Das BIOS hat anscheinend einen Bug, ich habs durch eine Linuxinstallation gefunden:
"PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved"

Diesen Bug findet man im Zusammenhang mit - TSCHINGDERASSABUMMTÄTERÄ - dem selben Realtec-Nic, den ich zum Testen genommen habe.
Und in der Tat, auf der Debian AMD64er Installation ist der Nic nicht ansprechbar, obwohl er korrekt erkannt wurde.

Es kann also gut sein, dass ich mir zwei Tage um die Ohren geschlagen habe, die sich von selbst erübrigen, wenn mein Intel-Nic da ist. Dennoch wird vorher noch anderer Speicher probiert.
 
vielleicht wäre der fehler ja auch mit dem BIOS-update behoben. das würde dir die restlichen tage ersparen (allerdings nur, wenn du dein BIOS-chipse dabei nicht grillst, was mir bisher bei so einer aktion noch nicht passiert ist).
 
vielleicht wäre der fehler ja auch mit dem BIOS-update behoben. das würde dir die restlichen tage ersparen (allerdings nur, wenn du dein BIOS-chipse dabei nicht grillst, was mir bisher bei so einer aktion noch nicht passiert ist).

Ja, die Scharweinlichkeit ist hoch. Ich werde aber nicht auf blauen Dunst hin das BIOS updaten, sondern hab mal Asus angeschrieben.
Ansonsten hab ich gleich nen Termin mit dem Kistenschieber, um versch. HW auszuprobieren, um Inkompatibilitäten auf die Schliche zu kommen und ggfls. auszuschliessen.
Wenn er als Verkäufer das Update machen will - seine Sache. Ich probier nicht gern auf blauen Dunst aus...
 
Auf diesen Bug stoße ich in meinem Bios auch, den hat so ziemlich jedes i945/965 Board afaik und hat was zu tun mit den PCI Ressourcen frei nach dem Motto Läuft unter Windows und der Rest interessiert uns nicht. Sollte also - zumindest im näheren Sinne - nichts mit deiner Onboard NIC zu tun haben. Im Linux Kernel gibt es afaik einen Patch der das Problem behebt, zumindest Ubuntu scheint in der Regel nicht über den Bug zu meckern.
 
Kann man unter FreeBSD auch softwareseitig beheben. Gab es letzten einen Thread auf freebsd-current@. Aber hier kann es nicht das Problem sein, da troll ein AMD-System hat. Mein Tipp wäre aber dennoch ein kaputtes BIOS :)
 
Also, das BIOS ist jetzt aktualisiert, der Fehler tritt immer noch auf.
Wir haben testweise mit nem GB-Riegel 677 und nem anderen NIC(dlink leider auch mit rl) getestet und die Kiste aber so richtig in die Knie gezwungen ohne das der Fehler auftrat.

Morgen kommt hoffentlich mein Intel-NIC und dann werden wir mit 2GB-Riegeln Kingston testen. Aber von Haus aus 800er, da es ja bei den Phenoms diese 1066er Restriktionen gibt.

Wenn das dann nicht auftritt wird noch mein Escalade reingefrickelt und damit getestet...
 
Sekunde mal.

Wichtig ist, dass du auch die richtige Spannung für den RAM einstellst, denn oft haben die Riegel ne non-Standard Spannung z.B. 2.1V statt 1.8. Sowas vergisst man gerne (Ich spreche aus Erfahrung, hat mich nen paar Minuten und nen Schrecken gekostet).
 
Danke, aber die Spannung ist korrekt eingestellt. Ich hab versucht an die unteren Grenzen zu gehen, daher weiss ichs sicher.
Hehe, ich hab grad meine Home-Partition rübergedumpt. Bis auf diesen Fehler läuft das Dingen so fluffig, wie ichs mir vorgestellt hab...
 
Es scheint einen weiteren Anhaltspunkt dazu zu geben.
Das Aususboard, auf dem der Fehler auftrat wurde gegen ein Gigabyteboard getauscht. Inzwischen hatte ich rausgefunden, dass der Fehler nur via ssh auftritt und hab sämtliche CPU-Optimierungen aus der make.conf rausgenommen. Das Problem war dadurch entschärft, nicht aber weg.
Das seltsame Speicherverhalten das beim Kopieren der _inaktive_ Speicher wie blöde anschwoll und innerhalb von ca. einer Stunde 8GB voll hatte blieb.

Das Verhalten blieb auch mit dem Gigabyteboard, aber es hatte keine Priorität, weil ich nie an irgendwelchen schaurigen Grenzen kam.

Jetzt kommts: Ich hatte in nem anderen Thread geschrieben, dass ich mir einen Rechner zusammenbaue, der extrem schallgedämpft sein wird und möglichst effizient sein soll.
Ich hatte noch das Asusboard und hab es dafür verwendet. Als CPU einen PhenomII X4 940

Das seltsame Verhalten ist weg.
OK, der Prozessor mit dem das Problem auftrat war ein 2.5Ghz Phenom X4 9850.
Ich hatte ihn damals gekauft, weil der 2.6er eine ewige Lieferzeit hatte.
Ich hatte jetzt die Möglichkeit einen 2.6er auf dem Gigabyteboard auszuprobieren. Der Fehler ist weg. Er tritt nur mit dem 2.5Ghz auf.
Der 2.5Ghz ist ein wenig verkaufter Kern, ich finde es leider nicht mehr wieder, aber meine, dass die wenigen Leute, die auch das Problem hatten alle den 9750(2.4), oder den 9850 wie ich hatten.

Dies Posting ist als Info für die Leute gedacht, die sich so tief im System bewegen. Mir selbst ist vollkommen unklar, ob es sich um einen CPU-Fehler, oder einen Kernelfehler handelt.
Ich hab auch leider keinen Zweiten 2.5er, um ausschliessen zu können, dass ich einfach ne kaputte CPU hatte.
Vielleicht kann ja jemand was mit den Infos anfangen.

[EDIT] Falls jemand auch den 2.5er Phenom hat kann er sich ja auch gerne melden. Wir könnten versuchen den Fehler auf seiner Maschine zu reproduzieren, um ausschliessen zu können, dass das nur eine fehlerhafte CPU war(woran ich nicht wirklich glaube, weil es mehrere Berichte mit dem selben Symptom gab)
 
Back
Top