I2C Timeouts mit ddbridge

  • Hast du mal mit den CPU Stromsparmodi gespielt?

  • Ich habe jetzt mal


    Intel SpeedStep Technology

    CPU C States Support

    Enhanced Halt State (C1E)


    alle auf "Disabled" gesetzt und den rsync laufen lassen.

    Nach gefühlt in etwa der Zeit, die vorher verging, bis der Fehler auftrat, kamen solche Meldungen:


    Mar 29 17:23:19 vdr3 kernel: [ 334.170901] CMCI storm detected: switching to poll mode

    Mar 29 17:28:20 vdr3 kernel: [ 634.723167] CMCI storm subsided: switching to interrupt mode

    Mar 29 17:29:21 vdr3 kernel: [ 696.086885] perf: interrupt took too long (2537 > 2500), lowering kernel.perf_event_max_sample_rate to 78750


    (dazwischen andere, normale VDR-Meldungen). Sowohl VDR als auch rsync liefen aber die ganze Zeit störungsfrei.

    Ich lasse das jetzt mal weiter laufen und beobachte...

  • Möglicherweise ist deine CPU oder deren Spannungsregler auf dem MB zu langsam und läuft beim wakeup in ein timeout, wenn sie wegen eines Interrupts aufgeweckt wird.

  • Selbst das Ausführen des Reboots dauert eine Weile. Aber immerhin schafft er es, wieder hochzukommen. Ein Reset ist nicht nötig.

    Man könnte versuchen, ob es reicht nur den VDR zu beenden und die Kartentreiber zu entladen

    (runvdr).


    Zur Belüftung des Gehäuses habe ich einen langsam drehenden Lüfter in Betrieb, so dass ein Wärmestau eigentlich auch ausgeschlossen sein dürfte.

    Trotzdem können einzelne Komponenten zu warm werden, wenn sie nicht genug Luft abbekommen.
    DVB-Hardware würde ich bei den geschilderten Symptomen inzwischen für unwahrscheinlich halten.


    Wenn der Prozessor zu warm wird und ins throttling gerät könnte das aber passen.

    Die CPU-Temperatur ist aber einfach zu überprüfen.



    Da jetzt einige Meldungen mit Interrupts kamen, wäre es interessant mal zu schauen, was sich da tut.

    Code
    1. watch -tn1  cat /proc/interrupts

    Wenn die Meldungen stimmen, muss irgend ein Gerät das System mit Interrupts fluten. Das müsste man eindeutig sehen können.


    Da der Fehler durch kopieren von Daten über das Netzwerk zu provozieren ist, gerät die Netzwerkkarte auch in Verdacht.

    Zu dem RTL8111 gibt es auch einen alternativen Treiber (r8168), der nicht im Kernel ist. Der könnte einen Versuch wert sein.

    Den musste ich anfangs (einige Jahre her) verwenden, weil der aus dem Kernel (r8169) noch nicht so recht wollte. Debian bietet den r8168 als DKMS-Paket (non-free) an, SuSE weiss ich leider nicht.


    Verteilen sich die Interrupts denn einigermassen gleichmässig über die CPU-Kerne?


    Was wäre denn als Alternative zum Asrock J3455M geeignet? Sinnvollerweise wohl von einem anderen Hersteller.

    Von Asrock gibt es einen Nachfolger mit J4105 Celeron (µATX).

    Mit der oder einer ähnlichen CPU gibt es sonst nur ITX-Boards. D.h. du hättest nur einen Slot.

    Da ist die Auswahl aber recht übersichtlich, ein zwei Boards pro Hersteller, insgesamt keine 10.

    Wenn man Asrock ausklammert, sieht es bei den aktuellen CPUs aber (noch?) schlecht aus.


    Bei den aktuellen Sockel 1151v2 Boards hat Fujitsu zwei im Angebot, recht interessant aussehen: D3642-B und D3643-H

    Intel NIC, sehr schön aufgeräumt und sparsam sollen die auch sein.

    Die Boards erinnern mich an die, die Intel früher selber verkauft hat.


    MSI hat auch "kleine", nicht überladene 1151v2 Boards mit Intel-NIC am draussen.

    Gruss
    SHF


  • Ohne Netzwerklast leuchten die ersten beiden LEDs (von der Hinterkante mit dem TAB2-Stecker her gezählt) permanent, die anderen 3 sind aus.


    Mit Netzwerklast blinkt die 5. LED. Sobald der Fehler auftritt leuchtet auch diese permanent, und ich meine, dass die dritte dann ganz schwach leuchtet.


    Den Downgrade auf BIOS 1.80 hat das Board angenommen, am Verhalten hat sich aber dadurch nichts geändert.

  • Man könnte versuchen, ob es reicht nur den VDR zu beenden und die Kartentreiber zu entladen

    (runvdr).

    Das reicht leider nicht. Der Treiber lässt sich meist auch gar nicht komplett entfernen, da noch Teile in Benutzung sind.

    Wenn der Prozessor zu warm wird und ins throttling gerät könnte das aber passen.

    Die CPU-Temperatur ist aber einfach zu überprüfen.

    Im Normalbetrieb mit langsam laufendem Lüfter und aktivem vaapidevice beträgt die CPU-Temparatur ca. 58 Grad.

    Lasse ich den Lüfter mit maximaler Geschwindigkeit laufen, geht sie runter auf ca. 48 Grad.

    In beiden Fällen, und auch ohne geladenes vaapidevice-Plugin, tritt der Fehler bei Netzwerklast nach kurzer Zeit auf. Ohne Netzwerklast läuft es stabil die ganze Nacht über.

    Da jetzt einige Meldungen mit Interrupts kamen, wäre es interessant mal zu schauen, was sich da tut.

    Hier die Interrupts nach einiger Zeit Betrieb (mit Netzwerklast) vor dem Fehler:

    Und hier kurze Zeit nachdem der Fehler auftrat:

  • Hi,

    mein Realtek driver/firmware


    ethtool -i enp1s0


    driver: r8169

    version: 2.3LK-NAPI

    firmware-version: rtl8168g-2_0.0.1 02/06/13

    expansion-rom-version:

    bus-info: 0000:01:00.0

    supports-statistics: yes

    supports-test: no

    supports-eeprom-access: no

    supports-register-dump: yes

    supports-priv-flags: no


    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

  • Ohne Netzwerklast leuchten die ersten beiden LEDs (von der Hinterkante mit dem TAB2-Stecker her gezählt) permanent, die anderen 3 sind aus.


    Mit Netzwerklast blinkt die 5. LED. Sobald der Fehler auftritt leuchtet auch diese permanent, und ich meine, dass die dritte dann ganz schwach leuchtet.


    Den Downgrade auf BIOS 1.80 hat das Board angenommen, am Verhalten hat sich aber dadurch nichts geändert.

    Die LEDs zeigen, daß der PCIe-Link instabil wird.

    Das gleiche hatte ich mit BIOS <1.60 auch. Mit dem 1.60 konnte ich es nicht mehr provozieren.

    Ich nehme also an, daß die in >=1.70 wieder etwas geändert haben.

    Leider kann man wohl auf das 1.60 nicht zurück.


  • 2 x DD Cine S2 V7A

    werden LNBs direkt aktiv über diese Karten mit Spannung versorgt? Wenn ja, ist der Spannungsstecker zum Netzteil hinten drauf?

    Ich frage deswegen, weil bei manchen PCB-Layouts vom PCIe auf dem MB die Stromversorgungspfade etwas ungünstig designt wurden. Dadurch könnte die PCIe Versorgung in die Knie gehen und instabil werden. DD empfiehlt ab 5 Watt LNB-Verbrauch den Stromstecker zu verwenden.

  • Ich nehme also an, daß die in >=1.70 wieder etwas geändert haben.

    Leider kann man wohl auf das 1.60 nicht zurück.

    Ich habe noch ein solches Board, welches noch BIOS 1.20 hat.

    Aber leider gibt es auf der ASRock Download-Seite die Version 1.60 nicht (mehr).

    Hast du die vielleicht noch und könntest sie mit zum Testen zur Verfügung stellen?

  • Wird die Netzwerklast und damit der Fehler nur durch die Datensicherung erzeugt (mit Fetsplattenzugriff) oder passiert das auch beim übertragen eines Live-Stream (ohne Diskzugriff) über das Netzwerk vom VDR?

    Ich habe versuchsweise mal das Videoverzeichnis auf eine über NFS gemountete Platte gelegt und vier gleichzeitige Aufnahmen gemacht. Kein Poblem. Möglicherweise kommen da aber nicht so viele Daten in so kurzer Zeit zusammen wie bei einem rsync.

  • Bei 60°C sollte thermal throttling eigentlich kein Thema sein.

    Die Interruptverteilung sieht für mich auch grob sinnvoll aus. eth0 und DDbridge sind auch unterschiedlichen CPUs zugeordnet.

    Die Zahlenwerte sind die aufgetretenen Interrupts seit Systemstart. Da ist es etwas schwer festzustellen, wenn ein Gerät amok läuft.

    Da müsste man schauen, ob einer der Zähler ungewöhnlich schnell hoch (>1000/s) läuft.


    Die Gesamtzahl der Interrupts pro Sekunde zeigt auch :

    Code
    1. vmstat 1

    (Das 1 aktualisiert sekündlich, die Ausgabe in eine Datei umleiten ist also nicht verkehrt.)

    Auch die anderen Werte von system und cpu könnten interessant sein. Erklaerung und Beurteilung der ausgegebenen Werte

    Wenn der Fehler auftritt müsste man eigentlich irgendwas sehen. Eventuell kann man aus dem Zustand in dem die CPU dann läuft Rückschlüsse ziehen was da passiert.


    Ich habe versuchsweise mal das Videoverzeichnis auf eine über NFS gemountete Platte gelegt und vier gleichzeitige Aufnahmen gemacht. Kein Poblem. Möglicherweise kommen da aber nicht so viele Daten in so kurzer Zeit zusammen wie bei einem rsync.

    Was passiert denn, wenn man den Prozessor etwas traktiert

    Code
    1. nice -n19 cat /dev/zero > /dev/null

    Natürlich einmal je CPU-Kern.


    Wenn das alleine keine Probleme verursacht, dann zusammen mit rsync.


    Unter Umständen verbessert sich die Stabilität dabei, weil der Prozessor nicht mehr runter taktet.

    Gruss
    SHF


  • Ich habe noch ein solches Board, welches noch BIOS 1.20 hat.

    Aber leider gibt es auf der ASRock Download-Seite die Version 1.60 nicht (mehr).

    Hast du die vielleicht noch und könntest sie mit zum Testen zur Verfügung stellen?

    Ich habe nur die vom J3355M (identisches Board nur mit 2-Core statt 4-Core Apollo-Lake).

    Man kann aber anscheinend die alten runterladen, wenn man den Download-Link per Hand anpasst.

    Soweit ich mich erinnere, mußte man auch erst 1.50 als "Bridge-BIOS" nehmen.