I2C Timeouts mit ddbridge

  • Mein aktueller VDR hat ein Asrock J3455M Motherboard mit aktuellem BIOS Version 1.90.

    Darin befinden sich


    2 x DD Cine S2 V7A

    1 x DuoFlex S2 V4A

    1 x DuoFlex C/C2/T/T2/ISDB-T Erweiterung

    1 x DD DuoFlex CI

    mit dem aktuellen Treiber 0.9.36 von hier.


    Zur Wiedergabe verwende ich vaapidevice.


    Das Ganze funktioniert soweit sehr gut, nur leider kommt es ab und zu zu einem I2C-Timeout, was sich im Log so niederschlägt:

    Die Performance geht dabei komplett in die Knie, bis irgendwann der VDR-Watchdog zuschlägt.

    Wenn der Rechner mal in diesem Zustand ist, hilft nur noch ein kompletter Reboot.


    Dem Hinweis von hier folgend habe ich in /etc/modprobe.d/ddbridge.conf "options ddbridge msi=0" eingetragen, was aber anscheinend nicht hilft.


    Im BIOS habe ich unter "Advanced -> Chipset Configuration" die "PCIE Link Speed" auf Gen1 und auch Gen2 gesetzt, hat aber auch nichts geholfen.


    Leider habe ich noch keine reproduzierbare Vorgehensweise gefunden, mit der man den Fehler provozieren kann. Er tritt sporadisch auf, und natürlich meistens zur Unzeit.


    Hat vielleicht jemand eine Idee, woran das liegen könnte, oder was ich noch ausprobieren könnte?


    Hier noch der Output von 'lspci', falls es was hilft:


    Klaus

  • Bei manchen DD Geräten kann man die Firmware updaten. Keine Ahnung, ob das auf deine zutrifft, und erst recht nicht, ob das für die Timeouts hilft. Aber mal gucken schadet nichts.

  • Hi,


    hab hier ein Asrock J4205-ITX was ja sehr ähnlich ist und hatte noch nie I2C timeouts (Kernel 4.15).


    der aktuelle dddvb Treiber ist 0.9.37.


    [1384566.969882] Digital Devices PCIE bridge driver 0.9.37, Copyright (C) 2010-17 Digital Devices GmbH

    [1384566.970221] ddbridge 0000:06:00.0: device name: Digital Devices Cine S2 V6.5 DVB adapter

    [1384567.451373] ddbridge 0000:07:00.0: device name: Digital Devices Cine CT V7 DVB adapter


    CU

    9000h

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

  • Mit Spread-Spectrum finde ich da nichts.


    Es gibt nur unter "Advanced\Chipset Configuration" "PCIE[1-3] Link Speed" mit jeweils Auto, Gen1 und Gen2.


    Unter "Advanced\CPU Configuration" habe ich


    Intel SpeedStep Technology Enabled

    CPU C States Support C1

    Enhanced Halt State (C1E) Enabled

    Intel Virtualization Technology Disabled

    VT-d Disabled

    Power Gear Normal Mode

  • Seit wann hast Du welches BIOS drauf?


    Ich habe die Erfahrung gemacht, das es vor 1.6 große Probleme mit z.B. der Cine gab. Mit der 1.6er ist es bei mir aber ganz stabil, auch mit extra Streßtest-Firmware. Neuere BIOSe habe ich nicht probiert.

  • Ich hatte längere Zeit das ursprünglich gelieferte BIOS 1.20 drauf, da der Online-Update im BIOS immer meinte, es gäbe nichts Neues. Nach einem Hinweis von Andreas McPherson habe ich dann manuell auf Version 1.90 (mit Zwischenstopp bei 1.70, weil ein direkter Update nicht möglich war) upgedatet. Die I2C-Probleme waren vor dem Update deutlich stärker, bestehen aber auch mit 1.90 noch, allerdings nicht mehr so oft. Ein Downgrade des BIOS auf 1.60 ist wahrscheinlich nicht möglich, oder?


    Ich werde morgen mal den Treiber 0.9.37 probieren.

    Hat sich in dem bezüglich I2C etwas geändert?

  • Eine Suche hier im Forum bringt ja etliche Treffer zu ddbridge und i2c-timeouts - zum Teil schon 6 Jahre alt und meistens in Kombination mit Asrock Boards. Eine finale Lösung habe ich nirgends herausgelesen.

    Auch wenn es möglicherweise ain anderes Problem ist (s. hier) und du die Treiberoption msi=0 schon ausprobiert hast würde ich, um es wirklich ausschließen zu können, mit der Kernel-Boot Option "pci=nomsi" MSI einmal global abschalten und beobachten (msi-howto Pkt.5.1 und 5.2).


    Ich habe übrigens die ITX Version von deinem Boardmit einer DVBSky Karte . Den i2c Fehler gibt es in dieser Kombination nicht (dafür andere Eigenarten bei den USB Ports - irgendwie finde ich das MB nicht ganz astrein obwohl VDR sonst gut drauf läuft).


    Helmut

  • Am I2C hat sich ewig nichts geändert. Da gibt es ja auch kein Problem.

    Das Problem ist immer entweder, daß der IRQ verloren geht, oder, daß der PCIe-Link ganz abbricht.

    Und dadurch gibt es halt dann Overflows im DMA und Timeouts im I2C.


    Bevor ich das 1.9er BIOS probiere, werde ich auch erst mal sehen, ob man zurück auf das 1.6er kann ...

  • Wenn der Rechner mal in diesem Zustand ist, hilft nur noch ein kompletter Reboot.

    Ein entladen und neu laden der Kernel-Module bringt nichts?

    Oder ist das schon nicht mehr möglich?


    "kompletter Reboot" heisst Linux mit reboot herunter fahren?

    Oder ist es nötig Reset zu drücken?



    Obwohl anscheinend viel in Richtung BIOS deutet:

    Die üblichen Verdächtigen, wie lose Kabel und Überhitzung der Tuner kann man ausschliessen?

    Irgendwann hatte jemand auch Probleme mit den Kabeln zu den Tunern. Abschirmen mit Alufolie hat da angeblich geholfen. Den Thread hab ich aber eben nicht finden können.

    Gruss
    SHF


  • Es sind in diesem Zustand praktisch keine Aktionen mehr möglich. Selbst das Ausführen des Reboots dauert eine Weile. Aber immerhin schafft er es, wieder hochzukommen. Ein Reset ist nicht nötig.


    Die Kabel sind alle gut angeschlossen. 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.

  • Ich muss mich korrigieren: nachdem der Fall beim Kopieren des Video-Directorys auf einen anderen Rechner (mit rsync) erneut aufgetreten ist, habe ich mal versucht, mich einzuloggen und konnte tatsächlich noch Befehle ausführen. Ich habe dann bei den Kernel-Boot Optionen "pci=nomsi" eingetragen und neu gebootet. Beim erneuten Kopieren des Video-Directorys kam es aber wieder zu dem Fehler.


    Ein Umstieg auf Treiber-Version 0.9.37 hat keine Verbesserung gebracht.


    Immerhin scheine ich jetzt eine Möglichkeit gefunden zu haben, den Fehler zu provozieren...


  • Hi,

    meine grub boot parameter sind

    GRUB_CMDLINE_LINUX_DEFAULT="i915.enable_guc_loading=1 i915.enable_guc_submission=1 pci=pcie_bus_safe quiet splash"

    GRUB_CMDLINE_LINUX="vmalloc=256MB"


    CU

    9000h

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

  • Vermutlich sicherst du über's Netzwerk. Falls sich LAN und der betreffende PCIe-Slot einen IRQ teilen, könnte es daran liegen. Vielleicht probierst du mal einen anderen PCIe-Slot.

  • Gruß dich.

    Ich habe vor übereinem Jahr auch schon etliche Versuche ausprobiert unter der Absprache mit nst. Siehe Link.

    Wenn ich mich recht erinnere gibt es für das Problem keinen Fix.


    Ich habe mir dann am Ende (nach einigen Wochen des rumprobierens mit neuen Kerneln und Treibern) einen anderen Empfänger zugelegt um mir weitere Kopfschmerzen erspart.


    Gruß

    VDR_1:

    Asus J3455-M, GT 710, SSD 240GB, 8GB DDR3, 1x DvbSky S950 with yavdr-ansible (testing)

    VDR_2:

    AsRock J3455, GT 710, SSD 120GB + SATA 400GB, 8GB DDR3, 1x DvbSky S952 with yavdr-ansible (testing)

    VDR_3_Testing:

    AtomiPi with Intel Atom x5-Z8350, 2GB DDR3, 16GB eMMC, 1x Sundtekt DVB-S with yavdr-ansible (testing)


  • Vermutlich sicherst du über's Netzwerk. Falls sich LAN und der betreffende PCIe-Slot einen IRQ teilen, könnte es daran liegen. Vielleicht probierst du mal einen anderen PCIe-Slot.

    Ich habe die Karte jetzt mal vom ersten (x1) in den zweiten (x16) Slot gesteckt (von hinten gesehen).

    Der Fehler trat aber genau so wieder auf:

    Code
    1. Mar 29 16:26:03 vdr3 kernel: [ 230.669864] ddbridge 0000:03:00.0: IA 0 0 ffffffff
    2. Mar 29 16:26:03 vdr3 kernel: [ 230.719990] ddbridge 0000:03:00.0: IA 0 0 ffffffff
    3. Mar 29 16:26:03 vdr3 kernel: [ 230.770204] ddbridge 0000:03:00.0: IA 0 0 ffffffff
    4. Mar 29 16:26:03 vdr3 kernel: [ 230.820262] ddbridge 0000:03:00.0: I2C timeout, card 0, port 0, link 0
    5. Mar 29 16:26:03 vdr3 kernel: [ 230.870365] ddbridge 0000:03:00.0: DDBridge IRS ffffffff
    6. Mar 29 16:26:03 vdr3 kernel: [ 230.970573] ddbridge 0000:03:00.0: IA 0 0 ffffffff