[vorläufig geklärt] Probleme mit forcedeth bekannt?

[dirk11]

Hi Leute,

ich habe jetzt schon ein paarmal beobachtet, dass einer meiner Rechner nicht mehr erreichbar ist, wenn sich im laufenden Betrieb der link-Status an seiner Netzwerkschnittstelle ändert (also z.B. der WLAN-Router neu gestartet wird).

Im syslog gibt es nur Einträge wie diese:

Code: Alles auswählen

Apr 10 20:08:30 rechner kernel: [25585.333854] forcedeth 0000:00:14.0 eth0: link down
Apr 10 20:08:53 rechner kernel: [25608.749039] forcedeth 0000:00:14.0 eth0: link up

Vollkommen logisch, link wech, link wieder da. Ansonsten gibt es überhaupt nichts auffälliges an Einträgen. Dennoch ist wie gesagt zweimal passiert, dass der Rechner danach weder von aussen per ping oder sonstwas erreichbar war noch selbst von innen heraus jemand im LAN erreichen konnte. Ich habe dann mal händisch das Netzwerkkabel ab- und wieder angesteckt, und danach ging's wieder.
Hat vielleicht jemand eine Erklärung für dieses merkwürdige Verhalten? Liegt es gar am Kernel, denn forcedeth scheint im Kernel integriert zu sein. Kernel ist 3.13-bpo1. Wheezy 64Bit.

[storm]

Naja, forcedeth -> nvidia, reicht als Qualitätsmerkmal fürs erste schon mal. Kuckt man in den Treiber, findet man zB.

Code: Alles auswählen

 *      Note: This driver is a cleanroom reimplementation based on reverse
 *      engineered documentation written by Carl-Daniel Hailfinger
 *      and Andrew de Quincey.

oder

Code: Alles auswählen

  /* Some NICs freeze when TX pause is enabled while NIC is
   * down, and this stays across warm reboots. The sequence
   * below should be enough to recover from that state.
   */

Also, wenn du unbedingt etwas verlässlicheres haben willst, solltest du dir evtl. eine andere NIC zulegen. Aber unter Umständen helfen vllt. die Modulparameter schon weiter. Zum Beispiel:

Code: Alles auswählen

phy_power_down ... "Power down phy and disable link when interface is down (1), or leave phy powered up (0)."

Villeicht bringt auch das Abschalten von MSI/MSIX eine Verbesserung (auch ein Modulparameter).

[dirk11]

Ok. Ne zusätzliche NIC soll vorerst nicht rein, frisst nur mehr Strom. Nur verwirren mich deine Satzfragmente gerade. Um welches Modul geht es genau? Es gibt tatsächlich ein Modul forcedeth (ich dachte immer, das sei in nv enthalten):

Code: Alles auswählen

# lsmod | grep forced
forcedeth              65339  0

Wo müsste ich da welche Parameter eintragen?

[smutbert]

Die möglichen Optionen zeigt dir

Code: Alles auswählen

# modinfo forcedeth
[…]
parm:           max_interrupt_work:forcedeth maximum events handled per interrupt (int)
parm:           optimization_mode:In throughput mode (0), every tx & rx packet will generate an interrupt. In CPU mode (1), interrupts are controlled by a timer. In dynamic mode (2), the mode toggles between throughput and CPU mode based on network load. (int)
parm:           poll_interval:Interval determines how frequent timer interrupt is generated by [(time_in_micro_secs * 100) / (2^10)]. Min is 0 and Max is 65535. (int)
parm:           msi:MSI interrupts are enabled by setting to 1 and disabled by setting to 0. (int)
parm:           msix:MSIX interrupts are enabled by setting to 1 and disabled by setting to 0. (int)
parm:           dma_64bit:High DMA is enabled by setting to 1 and disabled by setting to 0. (int)
parm:           phy_cross:Phy crossover detection for Realtek 8201 phy is enabled by setting to 1 and disabled by setting to 0. (int)
parm:           phy_power_down:Power down phy and disable link when interface is down (1), or leave phy powered up (0). (int)
parm:           debug_tx_timeout:Dump tx related registers and ring when tx_timeout happens (bool)

Die Parameter, die storm meint kannst du in eine beliebige .conf-Datei unter /etc/modprobe.d/ schreiben:

Code: Alles auswählen

options forcedeth phy_power_down=0 msi=0 msix=0

Allerdings würde ich dir raten die Optionen einzeln zu testen und nicht, wie ich hier geschreiben habe, alle auf einmal. (Ein Mainboard mit nvidia-Chipsatz, habe ich übrigens entsorgt, weil nicht nur forcedeth ständig Probleme verursacht hat, sondern auch firewire und usb…)

[dirk11]

Allerdings würde ich dir raten die Optionen einzeln zu testen und nicht, wie ich hier geschreiben habe, alle auf einmal.

Danke! Kannst du erklären, wofür msi und msix sind?

(Ein Mainboard mit nvidia-Chipsatz, habe ich übrigens entsorgt, weil nicht nur forcedeth ständig Probleme verursacht hat, sondern auch firewire und usb…)

Ich habe bzw. hatte ansonsten keinerlei Probleme mit dem Board bzw. dem Rechner. Entweder liegt's am letzten bpo-Kernel, oder am latest_trunk meines openWRT-Routers, das teste ich gerade noch. Es sind seit kurzem sehr merkwürdige "lags" drin: der durch ssh getunnelte gkrellm startet sehr hakelig, das Scrollen durch Verzeichnisse mit dem mc hakt, und am meisten aufgefallen ist es mir, weil das Streaming von mkv-Files zum Tablet nicht mehr ruckelfrei läuft. Problem dabei: momentan für mich schwer greifbar, ich habe so gar keinen Ansatzpunkt, wonach ich suchen könnte, denn es gibt keinerlei Fehlermeldungen. Wechsle jetzt gerade mal auf Kernel 3.12-bpo, mal sehen, was damit passiert.

[smutbert]

ich nicht, aber wikipedia http://de.wikipedia.org/wiki/Message-Si ... Interrupts

(auswendig hätte ich nur gewußt, dass das i für interrupts steht - der englische Wikipediaartikel wäre etwas ausführlicher. Nach dem englische Artikel müsste noapic als Kernelparameter ebenfalls msi, msix und noch ein bißchen mehr deaktivieren und könnte dein Problem auch lösen.)

[dirk11]

Interessant. Danke für deine Antwort!

Das Problem hat sich zwischenzeitlich Gott sei Dank geklärt:
nachdem ich meinen WLAN-Router downgegradet habe (das Problem ist mit dem Update aufgetreten, was sich im Nachhinein als Zufall herausgestellt hat) und dann mangels Erfolg auch den Kernel von 3.13-bpo auf 3.12-bpo downgegradet habe - auch erfolglos - ist mir die Meldung "MP-BIOS bug: 8254 timer not connected to IO-APIC" beim reboot aufgefallen. Diese Meldung gab es früher auch schonmal, aber immer nur nach Soft-Reboot. Also abgeschaltet. Meldung immer noch da. Und dann habe ich etwas erlebt, was ich seit dem C64 nur sehr, sehr selten erlebt habe: Stecker raus hat das Problem behoben! Ziemlich strange meiner Meinung nach, aber ich vermute einfach, dass der Esprimo irgendwie nie komplett in PowerOff geht. Jetzt funktioniert jedenfalls wieder alles wie gewohnt, vorher hat ein Stream sogar über LAN (statt WLAN) nicht mehr funktioniert.

noapic als grub-Parameter habe ich nicht probiert, u.a. weil ich noch nicht so ganz verstanden habe, was ich damit auslöse und was ich mir damit für Nachteile erkaufe.