I2C Timeouts mit ddbridge

kls · March 28, 2019 at 4:17 PM

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:

Code

Mar 22 00:05:03 vdr4 kernel: [14555.458752] ddbridge 0000:02:00.0: IA 4 128 ffffffff
Mar 22 00:05:03 vdr4 kernel: [14555.458770] ddbridge 0000:02:00.0: IA 4 128 ffffffff
Mar 22 00:05:03 vdr4 kernel: [14555.459698] ddbridge 0000:02:00.0: IA 0 128 ffffffff
Mar 22 00:05:03 vdr4 kernel: [14555.459715] ddbridge 0000:02:00.0: IA 0 128 ffffffff
Mar 22 00:05:03 vdr4 kernel: [14555.558896] ddbridge 0000:02:00.0: IA 4 128 ffffffff
Mar 22 00:05:03 vdr4 kernel: [14555.558917] ddbridge 0000:02:00.0: IA 4 128 ffffffff
Mar 22 00:05:03 vdr4 kernel: [14555.559833] ddbridge 0000:02:00.0: IA 0 128 ffffffff
Mar 22 00:05:03 vdr4 kernel: [14555.559850] ddbridge 0000:02:00.0: IA 0 128 ffffffff
Mar 22 00:05:04 vdr4 kernel: [14556.430304] ddbridge 0000:02:00.0: I2C timeout, card 0, port 1, link 0
Mar 22 00:05:04 vdr4 kernel: [14556.430311] ddbridge 0000:02:00.0: I2C timeout, card 0, port 3, link 0
Mar 22 00:05:04 vdr4 kernel: [14556.430316] ddbridge 0000:02:00.0: DDBridge IRS 00000000
Mar 22 00:05:04 vdr4 kernel: [14556.430318] ddbridge 0000:02:00.0: DDBridge IRS 00000000
Mar 22 00:05:04 vdr4 kernel: [14556.430322] ddbridge 0000:02:00.0: I2C cmd=0000d801 mon=0802000f
Mar 22 00:05:04 vdr4 kernel: [14556.430323] ddbridge 0000:02:00.0: I2C cmd=00002401 mon=0802000f
Mar 22 00:05:04 vdr4 kernel: [14556.466300] ddbridge 0000:02:00.0: I2C timeout, card 0, port 0, link 0
Mar 22 00:05:04 vdr4 kernel: [14556.466306] ddbridge 0000:02:00.0: DDBridge IRS 0000000a
Mar 22 00:05:04 vdr4 kernel: [14556.466310] ddbridge 0000:02:00.0: I2C cmd=0000d001 mon=0802000f
Mar 22 00:05:05 vdr4 kernel: [14557.454304] ddbridge 0000:02:00.0: I2C timeout, card 0, port 1, link 0
Mar 22 00:05:05 vdr4 kernel: [14557.454307] ddbridge 0000:02:00.0: I2C timeout, card 0, port 3, link 0
Mar 22 00:05:05 vdr4 kernel: [14557.454311] ddbridge 0000:02:00.0: DDBridge IRS 0000000b
Mar 22 00:05:05 vdr4 kernel: [14557.454312] ddbridge 0000:02:00.0: DDBridge IRS 0000000b
Mar 22 00:05:05 vdr4 kernel: [14557.486316] ddbridge 0000:02:00.0: I2C timeout, card 0, port 0, link 0
Mar 22 00:05:05 vdr4 kernel: [14557.486322] ddbridge 0000:02:00.0: DDBridge IRS 0000000a
Mar 22 00:05:05 vdr4 kernel: [14557.486326] ddbridge 0000:02:00.0: I2C cmd=0000d001 mon=0802000f

Display More

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:

Code

00:00.0 Host bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Host Bridge (rev 0b)
00:02.0 VGA compatible controller: Intel Corporation Device 5a85 (rev 0b)
00:0e.0 Audio device: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster (rev 0b)
00:0f.0 Communication controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Trusted Execution Engine (rev 0b)
00:12.0 SATA controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SATA AHCI Controller (rev 0b)
00:13.0 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #1 (rev fb)
00:13.1 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #2 (rev fb)
00:13.2 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #3 (rev fb)
00:13.3 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #4 (rev fb)
00:15.0 USB controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series USB xHCI (rev 0b)
00:1f.0 ISA bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Low Pin Count Interface (rev 0b)
00:1f.1 SMBus: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SMBus Controller (rev 0b)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
02:00.0 Multimedia controller: Digital Devices GmbH Cine V7
04:00.0 Multimedia controller: Digital Devices GmbH Cine V7

Display More

Klaus

jrie · March 28, 2019 at 4:52 PM

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.

kls · March 28, 2019 at 4:58 PM

Die Firmware der Cine S2 V7A ist aktuell.

Sorry, hatte ich vergessen zu erwähnen.

Piet · March 28, 2019 at 6:50 PM

Ich habe im Hinterkopf noch irgendwas mit Spread-Spectrum und Asrock-Boards, gibt's im PCI-E Setup die Möglichkeit das abzuschalten?

9000H · March 28, 2019 at 8:48 PM

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.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

kls · March 28, 2019 at 8:50 PM

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

kls · March 28, 2019 at 8:52 PM

9000H Wo findet man denn den 0.9.37-er Treiber?

Auf https://github.com/DigitalDevices/dddvb/releases geht es nur bis 0.9.36.

9000H · March 28, 2019 at 9:05 PM

Hi,

einfach mit git clone https://github.com/DigitalDevices/dddvb.git auschecken.

CU

9000h

rjkm · March 28, 2019 at 9:11 PM

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.

kls · March 28, 2019 at 9:22 PM

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?

HelmutB † · March 28, 2019 at 9:26 PM

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

9000H · March 28, 2019 at 9:35 PM

Hi,

ich hab noch ein altes Bios drauf

Code

BIOS Information
    Vendor: American Megatrends Inc.
    Version: P1.40
    Release Date: 07/14/2017

und hab auch noch einen PCI-X1 Multiplier da mein Board ITX ist. (https://www.amazon.de/gp/product/B075KNH1GM)

CU

9000h

rjkm · March 28, 2019 at 10:15 PM

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 ...

SHF · March 29, 2019 at 12:28 AM

Quote from kls

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.

kls · March 29, 2019 at 10:48 AM

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.

kls · March 29, 2019 at 11:49 AM

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...

9000H · March 29, 2019 at 12:21 PM

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

jrie · March 29, 2019 at 12:27 PM

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.

Diablo · March 29, 2019 at 12:55 PM

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ß

kls · March 29, 2019 at 4:31 PM

Quote from jrie

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

Mar 29 16:26:03 vdr3 kernel: [  230.669864] ddbridge 0000:03:00.0: IA 0 0 ffffffff
Mar 29 16:26:03 vdr3 kernel: [  230.719990] ddbridge 0000:03:00.0: IA 0 0 ffffffff
Mar 29 16:26:03 vdr3 kernel: [  230.770204] ddbridge 0000:03:00.0: IA 0 0 ffffffff
Mar 29 16:26:03 vdr3 kernel: [  230.820262] ddbridge 0000:03:00.0: I2C timeout, card 0, port 0, link 0
Mar 29 16:26:03 vdr3 kernel: [  230.870365] ddbridge 0000:03:00.0: DDBridge IRS ffffffff
Mar 29 16:26:03 vdr3 kernel: [  230.970573] ddbridge 0000:03:00.0: IA 0 0 ffffffff

Participate now!