I2C Timeouts mit ddbridge

  • Da es ja bei rjkm geht, könnte es auch am Kernel liegen.

    Anfangs gab es Probleme, weil die Boards noch nicht unterstützt waren, das sollte aber jetzt von Tisch sein.

    Dann meine ich mich zu erinnern, dass es auch mit den Spectre/Meltdown Patches und einigen PCIe Devices Ärger gab.

    Die sollte man zum Test mal deaktivieren. Aber allein das ist wohl schon ein umfangreicheres Thema: Ubuntu: MitigationControls

    SuSE ist da, zumindest anfangs, einen eigenen Weg gegangen. Die haben da einiges an zurück portiert.

    Im Zweifelsfall würde ich es noch mit einem neuen Kernel, bzw. einer anderen Distro (am besten der von rjkm ) versuchen.

    Gruss
    SHF


  • Ich habe versuchsweise mal das Videoverzeichnis auf eine über NFS gemountete Platte gelegt und vier gleichzeitige Aufnahmen gemacht. Kein Poblem.

    Jetzt wäre ein anderer Test noch interessant -ein rsync ohne Netzwerk z.B auf eine USB-Disk oder zumindest in eine andere Partition oder Unterverzeichnis auf der lokalen Disk. Vielleicht kann man dann den Netzwerkadapter als Mitverursacher auschließen.

    Helmut

  • Ich habe jetzt das J3455M gegen eines getauscht, das noch BIOS 1.20 hatte, und dieses auf 1.60 upgedatet.

    Der Fehler tritt auch hier auf, so dass die Tatsache, dass es bei rjkm keine Probleme gibt, offensichtlich nicht mit der BIOS-Version zusammenhängt.


    Weitere Tests mach ich in den nächsten Tagen.

    rjkm welche Linux-Distri und welchen Kernel verwendest du denn?

  • Debian unstable mit Standard Debian kernel 4.19.0-1 + mein dddvb git (letzteres hat keine Änderungen, die bzgl. des Problems relevant wären).


    Da aber wirklich der PCIe-Link "wackelt", glaube ich nicht, daß es am Kernel liegt, eher an Einstellungen an den PCIe-PHYs. Und die werden im Kernel soweit ich weiß normalerweise nicht angefaßt, nur im BIOS.

    Da ich die Probleme, als sie noch auftraten, bei weiterer Belastung der CPU hatte (ich habe immer zum Test ein Kernel gleichzeitig gebaut), kann natürlich noch ein Unterschied ziwschen dem J3355M und dem J3455M bestehen, da letzterer 2 Kerne mehr hat.

  • PCIe wackelt? Irgendwelche interrupts tauchen schneller auf als die CPU erwartet, die CPU beschäftigt sich nur noch damit und wird langsam für alles andre.


    Nach etwas googlen steht CMCI für 'Corrected Machine Check Interrupt', also ein hardware error flag, während die grub doku in dem Zusammenhang auf 'shared banks', also den Speicher verweist. Anscheinend hat jede Speicherbank einen eigenen Counter und fehler werden dann doppelt gemeldet. Machine check error deutet aber auch darauf hin, dass es ein hardware error ist, aber nicht nur der Speicher in Frage käme.


    https://en.wikipedia.org/wiki/Interrupt_storm

    https://access.redhat.com/solutions/367773


    mce=no_cmci

    Disable CMCI(Corrected Machine Check Interrupt) that

    Intel processor supports. Usually this disablement is

    not recommended, but it might be handy if your hardware

    is misbehaving.

    Note that you'll get more problems without CMCI than with

    due to the shared banks, i.e. you might get duplicated

    error logs.

  • off topic: Boah ... das liest sich ja wie ein Krimi ... bin ich gespannt auf den "Mörder"! :thumbup:

    MyVDR: yaVDR-Ansible - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod *broken*
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • ..im Zweifelsfall ist es immer der Gärtner.

  • Ich habe jetzt https://cdn.kernel.org/pub/lin…v4.x/linux-4.19.32.tar.xz geholt und installiert (auf dem openSUSE-System, wo alle bisherigen Versuche stattgefunden haben). Mit diesem Kernel lief der rsync zwar etwas länger als mit dem vorherigen Kernel, der Fehler trat aber auch wieder auf.


    Bei diesem Kernel ist der ddbridge-Treiber 0.9.33 dabei. Wenn ich die Version 0.9.37 übersetze erhalte ich bei 'make install'

    und bei dem Versuch, ihn zu laden


    modprobe: ERROR: could not insert 'ddbridge': Invalid argument


    Weiß jemand, was da schief läuft?

    Ich würde gerne noch die Kombination Kernel 4.19.32 mit ddbridge 0.9.37 testen.

  • Falsche Kernel-Header? Ist aber nur geraten.

    Im Zweifelsfall alle deinstallieren, die nicht verwendet werden sollen.

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

    Gibt es eine Beschreibung was die genau anzeigen?

    ich konnte nichts finden.


    Code
    1. lspci -vv

    Gibt einiges an Einstellungen der PCIe Geräte aus.

    Das könnte man auch noch vergleichen, vielleicht sieht man da Unterschiede.


    Zum BIOS:

    Das jeweilige vom J3355M und J3455M ist binär identisch.

    Daran kann es jedenfalls nicht liegen, dass es bei rjkm geht und bei kls nicht.

    Gruss
    SHF


    The post was edited 1 time, last by SHF: "BIOS" ergänzt. ().

  • Ich bin jetzt wieder auf meinen ursprünglichen Kernel 4.12.14 zurückgegangen und habe den rsync nicht über das Netzwerk geschickt, sondern auf eine lokale (externe) USB-Platte. Dieser Versuch läuft inzwischen seit eineinhalb Stunden störungsfrei (der rsync über das Netzwerk brachte den Fehler immer bereits nach kurzer Zeit). Parallel dazu lasse ich 8 gleichzeitige Aufnahmen auf 4 Devices laufen!

    Man kann also wohl davon ausgehen, dass das Problem am Netzwerktreiber liegt (wie hier bereits vermutet).

    Allerdings läuft hier bereits der Treiber r8169:


    #> ethtool -i eth0

    driver: r8169

    version: 2.3LK-NAPI

    firmware-version: rtl8168e-3_0.0.4 03/27/12

    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


    Soeben kam im Log diese Meldung:


    kernel: [ 6046.137805] r8169 0000:01:00.0: invalid large VPD tag 7f at offset 0


    Der rsync, die 8 Aufnahmen und die Wiedergabe laufen aber störungsfrei weiter.

    Jetzt habe ich parallel dazu nochmal den rsync über das Netzwerk gestartet und nach wenigen Sekunden trat der Fehler wieder auf.

    Den Output von 'lspci -vv' hänge ich an (zu lang für die Message).


    Hat jemand eine Idee, was ich als nächstes versuchen könnte?

  • Glaub zwar nicht, dass es dir viel hilft (weil offenbar andere Karte mit anderem Chipset), aber hier meine Ausgabe von "lspci -vv" für "Ethernet".

    Mir fällt zB auf, dass bei dir unter "Capabilities" öfter "+" steht, wo bei mir ein "-" ist; hab aber keine Ahnung, ob das was bedeutet.


    MyVDR: yaVDR-Ansible - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod *broken*
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • Piet Ein PCIe-Slot wäre zwar frei, der Einbauplatz ist aber belegt durch eine Receiver-Karte.


    9000H Hab den Realtek-Treiber installiert:

    Der Fehler trat aber beim rsync nach wenigen Sekunden wieder auf :-(.

  • Könnten vielleicht mal einige von euch versuchen, ob sie den Fehler, den ich hier beobachte, nachvollziehen können?

    Die Vorgehensweise ist:

    - ein System mit DD Cine S2 V7A

    - laufender VDR

    - ein großes Verzeichnis (z.B. das Video-Directory) mit 'rsync -a' über das Netzwerk auf einen anderen PC kopieren

    - das Logfile im Blick halten und auf Meldungen wie im Eingangspost achten

    Nach kurzer Zeit tritt damit bei mir der Fehler zuverlässig auf.

    Wäre interessant, ob das auch bei anderen passiert.


    ACHTUNG: sobald der Fehler auftritt hilft nur noch ein Reboot! Also nicht während "produktivem" Betrieb testen!

  • Ein "Workaround" wäre eventl. eine USB Netzwerkkarte zu verwenden. Das Board hat auch ein USB-C Anschluss onboard.

    Muss man sehen wie das da mit Treibern und vor allen Dingen mit Geschwindigkeit bestellt ist...

    Nur so als Idee.

  • Hallo,

    also das wäre für mich kein "Workaround" wenn schon eine Lan Karte einbauen.

    Eine Intel wäre eine Option.

    speed

  • Naja, wenn der freie PCIe Slot aber von der Tunerkarte überlagert ist...