I2C Timeouts mit ddbridge

Diablo · 12. April 2019

Wie ich oben bereits erwähnt hatte, hatte ich die gleichen Probleme mit einer V6.5 und dem selben MB.

Es gibt jedoch Nutzer die diese Karte nutzen ohne das MB.

Ich hatte hier zwei Boards von verschiedenen Herstellern mit einem J3455 in Kombination der V6.5 und beides führte zu Timeout- Problemen.

kls · 12. April 2019

Hier noch ein interessantes Ergebnis:

Versuch:

- Setup wie hier beschrieben.

- 4 parallele Aufnahmen auf dem ARD-Transponder (Das Erste HD, SWR BW HD, arte HD und SWR RP HD).

- Die CorrErr+ Flags gelöscht.

Ergebnis:

Auch nach einer knappen Stunde mit den 4 parallelen Aufnahmen auf einer Cine S2 V7A war kein CorrErr Flag auf '+'.

Nach ein paarmal Umschalten des Live-Kanals (zwischen den vieren, auf denen Aufnahmen liefen) war sowohl bei der ddbridge als auch der Gegenstation das CorrErr+ gesetzt.

Bei diesem Versuch wurden mit Sicherheit keine Spannungsänderungen am LNB gemacht, da ja nur *ein* Device verwendet wurde und darauf Aufnahmen liefen.

An der Last der Datenübertragung (immerhin 4 volle HD Kanäle) liegt es offensichtlich auch nicht, denn die Aufnahmen liefen eine knappe Stunde lang vollkommen problemlos.

Schlussfolgerungen:

Es ist also offensichtlich nur eine winzige Kleinigkeit, die dazu führt, dass die ddbridge in den Zustand CorrErr+ geht.

Es muss irgend etwas mit der Kanalumschaltung, also dem Setzen der PIDs zu tun haben.

Ich kann mir nicht vorstellen, dass es mit der Stromversorgung oder dem Motherboard zu tun hat, denn dafür geht es zu lange und auch unter Last gut.

kls · 12. April 2019

Zitat von HelmutB

Vielleicht noch einmal als Anregung z.B. TP-Link UE300 (Herstellerinfo auf der Seite ganz unten).

Hab mir einen UE330 bestellt und damit getestet.

Der Fehler tritt damit genauso auf, wie mit dem onboard NIC.

HelmutB · 12. April 2019

Nach deinen vielen erfolglosen Versuchen in der Zwischenzeit hab ich das schon fast befürchtet.

Argus hat natürlich recht - USB hängt auch am PCI-Bus - sieht man ja mit lspci. Daher kann der fehlerfreie rsync auf eine USB-Disk nur Zufall gewesen sein.

Nur um sicher zu sein - hast du das Onboard-LAN im Bios deaktiviert ?

Helmut

kls · 12. April 2019

Ja, das Onboard-LAN war für diesen Test im BIOS deaktiviert.

Ich hab jetzt zur Sicherheit nochmal den rsync auf die lokal gemountete USB-Disk gemacht.

Dabei treten auch sofort CorrErr+ auf, aber es kommt kein I2C-Timeout. Und das während einer ganzen Stunde und trotz zweier parallel laufender Aufnahmen.

Ein unmittelbar nach diesem Versuch gestarteter rsync über das Netzwerk dagegen führte bereits nach kurzer Zeit wieder zum Fehler.

HelmutB · 13. April 2019

Jetzt wird es mysteriös.

Vielleicht hat es eher mit DMA zu tun. In deinem 1.Post sieht man

Code

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

Die erste Meldung ist ein Fehler beim lesen des DMA_BUFFER_CONTROL registers in ddbridge.core.c. Das Wert in 'ctrl' mit 0xffffffff ist sicher kein regulärer Rcükgabewert (der i2c Fehler kommt 1 Sekunde später - das ist das genau das Timeout nach dem Schreiben von i2c-commands)

Code: ddbridge.core.c

static u32 ddb_input_avail(struct ddb_input *input)
{
    struct ddb *dev = input->port->dev;
    u32 idx, off, stat = input->dma->stat;
    u32 ctrl = ddbreadl(dev, DMA_BUFFER_CONTROL(input->dma));

    idx = (stat >> 11) & 0x1f;
    off = (stat & 0x7ff) << 7;

    if (ctrl & 4) {
        dev_err(dev->dev, "IA %d %d %08x\n", idx, off, ctrl);
        ddbwritel(dev, stat, DMA_BUFFER_ACK(input->dma));
        return 0;
    }
    if (input->dma->cbuf != idx)
        return 188;
    return 0;
}

Alles anzeigen

Im ddbridge Modul gibtes ein paar Parameter für dei DMA Behandlung .

'alt_dma' ist für die art Speicherallizierung (kmalloc oder alloc_coherent). Bei ARM Cpus wird er auf 1 gestzt, sonst 0 (vermutlich - er wird nicht wirklich initialisiert). Versuche es einmal mit 'alt_dma=1" (und sicherheitshalber auch dezidiert mit 'alt_dma=0' )

Das gibt es noch Parameter für Buffergröße und Anzahl. Vielleicht auch hier experimentieren.

Und dann noch 'no_init' ("do not initialize most devices" ) was auch immer dann passiert).

Helmut

kls · 13. April 2019

Mit "alt_dma=1" tritt der Fehler auf.

Ebenso mit "alt_dma=0", "dma_buf_num=32" und "dma_buf_size=43".

Mit "no_init=1" werden gar keine DVB-Devices angelegt.

HelmutB · 13. April 2019

Es wäre auch zu schön gewesen.

Unter der Annahme das das Ergebnis von ddbreadl(dev, DMA_BUFFER_CONTROL(input->dma) mit 0xffffffff kein gültiger Wert ist, hat der Test von Bit2 (0x04 - DMA_ERR ?) aber keinen Sinn und das darauffolgende ddbwritel(dev, stat, DMA_BUFFER_ACK(input->dma)) ist vielleicht nicht die richtige Antwort in dieser Situation.

Wenn du den ddbridge Treiber selbst bauen kannst wäre ein if (ctrl == 0xffffffff) return 0; noch einen Versuch Wert. Vielleicht ist es nur eine temporäre "Leseschwäche".

db_input_avail(struct ddb_input *input) wird übrigens von ts_poll() und ts_read() verwendet.

Helmut

kls · 13. April 2019

Ich habe jetzt mal ddb_input_avail() so geändert:

Code

static u32 ddb_input_avail(struct ddb_input *input)
{
        struct ddb *dev = input->port->dev;
        u32 idx, off, stat = input->dma->stat;
        u32 ctrl = ddbreadl(dev, DMA_BUFFER_CONTROL(input->dma));
        if (ctrl == 0xffffffff) {//XXX
                printk(KERN_INFO "*** ddb_input_avail()\n");
                return 0;
        }

        idx = (stat >> 11) & 0x1f;
        off = (stat & 0x7ff) << 7;

        if (ctrl & 4) {
                dev_err(dev->dev, "IA %d %d %08x\n", idx, off, ctrl);
                ddbwritel(dev, stat, DMA_BUFFER_ACK(input->dma));
                return 0;
        }
        if (input->dma->cbuf != idx)
                return 188;
        return 0;
}

Alles anzeigen

Die eingebaute Ausgabe erscheint aber nicht.

Also habe ich in ddbreadl() eine Ausgabe eingebaut:

Code

u32 ddbreadl(struct ddb *dev, u32 adr)
{
        if (unlikely(adr & 0xf0000000)) {
                unsigned long flags;
                u32 val, l = (adr >> DDB_LINK_SHIFT) & 3;
                struct ddb_link *link = &dev->link[l];

                spin_lock_irqsave(&link->lock, flags);
                gtlw(link);
                ddblwritel0(link, adr & 0xfffc, link->regs + 0x14);
                ddblwritel0(link, 3, link->regs + 0x10);
                gtlw(link);
                val = ddblreadl0(link, link->regs + 0x1c);
                spin_unlock_irqrestore(&link->lock, flags);
                if (val == 0xffffffff) printk(KERN_INFO "*** ddbreadl() A\n");//XXX
                return val;
        }
        u32 val = readl(dev->regs + adr);//XXX
        if (val == 0xffffffff) printk(KERN_INFO "*** ddbreadl() B\n");//XXX
        return val;//XXX
        //XXX return readl(dev->regs + adr);
}

Alles anzeigen

und es erscheint im Fehlerfall:

Code

Apr 13 15:44:12 vdr3 kernel: [  417.991826] *** ddbreadl() B
Apr 13 15:44:12 vdr3 kernel: [  417.991836] ddbridge 0000:02:00.0: I2C timeout, card 0, port 0, link 0
Apr 13 15:44:12 vdr3 kernel: [  418.041966] *** ddbreadl() B
Apr 13 15:44:12 vdr3 kernel: [  418.041969] ddbridge 0000:02:00.0: DDBridge IRS ffffffff
Apr 13 15:44:13 vdr3 kernel: [  419.114403] *** ddbreadl() B
Apr 13 15:44:13 vdr3 kernel: [  419.114413] ddbridge 0000:02:00.0: I2C timeout, card 0, port 0, link 0
Apr 13 15:44:13 vdr3 kernel: [  419.164550] *** ddbreadl() B
Apr 13 15:44:13 vdr3 kernel: [  419.164552] ddbridge 0000:02:00.0: DDBridge IRS ffffffff
Apr 13 15:44:14 vdr3 kernel: [  420.176887] *** ddbreadl() B

Es muss sich also wohl um eine andere Aufrufstelle handeln. Der Returnwert von ddbreadl() wird aber so gut wie nirgends auf 0xffffffff geprüft. Die einzige Stelle, wo man hier sinnvoll eingreifen könnte, ware wohl direkt in ddbreadl(). Aber ob man da einfach stattdessen 0x00000000 zurückgeben kann?

kls · 13. April 2019

Noch was: ich habe jetzt mal nicht gleich neu gebootet, sondern erst

rmmod ddbridge cxd2099 lnbh25 stv6111 stv0910 cxd2843 dvb-core

und dann

modprobe ddbridge

gemacht. Der erste Befehl lief ohne Fehlermeldung, beim zweiten kam aber im Log

Apr 13 15:53:32 vdr3 kernel: [ 977.989820] ddbridge 0000:02:00.0: Refused to change power state, currently in D3

Apr 13 15:53:32 vdr3 kernel: [ 978.240487] ddbridge 0000:02:00.0: device name: Digital Devices Cine S2 V7 Advanced DVB adapter

Apr 13 15:53:32 vdr3 kernel: [ 978.290495] *** ddbreadl() B

Apr 13 15:53:32 vdr3 kernel: [ 978.290497] ddbridge 0000:02:00.0: cannot read registers

Apr 13 15:53:32 vdr3 kernel: [ 978.290499] ddbridge 0000:02:00.0: fail

Apr 13 15:53:32 vdr3 kernel: [ 978.390862] ddbridge: probe of 0000:02:00.0 failed with error -1

Anscheinend ist die ddbridge da in einem Zustand, aus dem ein Ent-/Neu-Laden des Treibers nicht mehr herausführt. Lediglich ein Reboot des ganzen PCs hilft.

Fourty2 · 13. April 2019

Hallo Klaus,

naja, wenn die Meldung des I²C Timeouts stimmt, hält irgendein Stück der Hardware die I²C CLK und/oder DTA auf Masse und ist in diesem Zustand abgestürzt.
D.h. die I²C Takt- und/oder Datenleitung ist vom (abgestürzten) I²C-Slave auf Masse gezogen worden (Clockstretch / ACK) und noch immer dort.
Falls ein ACK-Hänger (Data = Lo) vorliegt, helfen eventuell manuelle CLK-Pulse. Ist die CLK auf Masse (Clock-Stretch), ist Ende-Gelände bis zum Hardware-Reset (oder Power-Off).

Stefan

jrie · 13. April 2019

Ich habe einen Octopus LE und daran ein FlexCI mit CAM drin.

Bei meinen letzten Tests konnte ich darüber 4 verschlüsselte Sender gleichzeitig fehlerfrei aufnehmen.

Jetzt wollte ich mal gucken, was bei mir passiert mit mehreren Aufnahmen und Netzwerkverkehr.

Aus irgendeinem Grund gehen derzeit nicht mal mehr zwei Aufnahmen, es gibt Aussetzer ab der zweiten Aufnahme.

Jetzt das Interessante: nur wenn es Aussetzer gibt, sehe ich im syslog solche Meldungen

Code

2019-04-13T16:45:46.397472+02:00 vdr kernel: [  687.280156] ddbridge 0000:03:00.0: IA 7 62976 00000007

Die timeouts bekomme ich nicht.

Nach einem Test mit 4 Aufnahmen und Netzwerkverkehr gab es dann selbst mit einer Aufnahme Aussetzer. Erst nach reboot ging dann wenigstens eine Aufnahme wieder fehlerfrei.

Mein Asrock Motherboard hat eine AMD 770 Northbridge und ich benutze openSuse.

Es hängt sich da also was auf, was erst durch reboot in Ordnung kommt.

Bei einem zweiten Test konnte ich das Aufhängen nicht reproduzieren.

jrie · 13. April 2019

Das war auf einem vdr-2.2 mit vielen Plugins und patchen. Jetzt habe ich noch mal auf einem minimalen vdr-2.4 getestet. Da laufen die 4 Aufnehmen plus Netzwerkverkehr tadellos. ~~(Nur beim Beenden der Aufnahmen gibt es „video data stream broken“ Meldungen).~~

Sorry, falls das für Verwirrung gesorgt hat.

Irgendwas an dem vdr-2.2 ist nicht in Ordnung, wußte ich vorher noch gar nicht ...

HelmutB · 13. April 2019

Zitat von kls

Aber ob man da einfach stattdessen 0x00000000 zurückgeben kann?

0x0 ziemlich sicher auch nicht das gewünschte Egebnis. readl() liest vom DMA-Buffer und bekomt eben 0xffffffff zurück. Aus irgendeinem Grund funktioniert irgendwann das DMA lesen/schreiben nicht. Das i2c timeout kommt möglicherweise auch deshalb, weil das writel() den Befehl gar nicht richtig absetzen kann.

Und weil das nur bei Netzwerkverkehr auftritt macht die Sache noch seltsamer.

Du könntest bei ddbreadl() noch die Ziel-Addressen ausgeben. Ob das wirklich einen Aufschluß gibt ist aber fraglich.

Helmut

jrie · 13. April 2019

Mein Test zeigt, dass man mit zu vielen Plugins und Patchen die ddbridge stören kann.

@Klaus hast du schon mal ganz minimal getestet, und kommen die Fehler dann auch?

HelmutB · 13. April 2019

Eine kleine Richtigstellung - es gibt die Probleme bei lesen/schreiben der in einen virtuellen Kernel-Speicherberich gemappten PCI-Register der DD - und nicht mit dem DMA Buffer. Ich bin leider kein PCI/DMA Spezialist und musste mich erst schlauer machen.

Helmut

kls · 13. April 2019

Zitat von jrie

@Klaus hast du schon mal ganz minimal getestet, und kommen die Fehler dann auch?

Ich benutze nur das vaapidevice Plugin.

Aber da der Fehler auch ohne jegliches Ausgabe-Device auftritt, kann es auch nicht an vaapidveice liegen.

HelmutB · 13. April 2019

Es gab/gibt von Daniel Scheller auf patchwork patchwork.kernel.org eine save_ddbreadl() Implementierung die den Fall von 0xffffffff prüft und dann 0 zurückgibt. Vielleicht kann man das in diesem Sinn an ein paar Stellen im Treiber doch übernehmen.

Helmut

Edit: bzw. nach einem ddbreadl() Fehler kein ddbwritel() mehr anwenden.

Edit2: das kann aber bei i2c _xfer nicht angewendet werden, da dieser mit leider immer einem ddbwritel() beginnt

SHF · 14. April 2019

Von diesem "I2C timeout" scheint es (mindestens) zwei Versionen zu geben.

Der feine Unterschied war mir bislang nicht bekannt. Den Thread: "Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren" hatte ich nicht verfolgt.

Einmal die "normalen" Timeouts, die manchmal mit "MSI=0" zu beheben ist.

Und dann die mit "IRS ffffffff".

Diese treten anscheinend nur oder hauptsächlich auf Apollo-Lake-SOCs auf.

Auch wenn da irgendwo von Asrock geschrieben wird, halte ich den Boardhersteller nicht für ausschaggebend.

Zitat von nst

das ist ein Problem zwischen Board und Karte bzw. dessen FPGA und nach aktuellem Kenntnisstand nicht per Treiberupdate fixbar

Zitat von nst

Wenn ddbridge anfängt, I2C Timeouts ins Kernellog zu loggen, und hinter "IRS" steht "ffffffff", bedeutet das zu 99% nicht, dass zu irgendeiner Zeit Interrupts (egal, ob MSI oder Legacy/PIN based - msi=0) verloren gegangen sind, sondern dass die Kommunikation zwischen PCIe-Bus und Karte weggeschmiert ist (ffffffff = Fehler beim Lesen von IOMem).

Zitat von kls

Es ist also offensichtlich nur eine winzige Kleinigkeit, die dazu führt, dass die ddbridge in den Zustand CorrErr+ geht.

Viel ist es wirklich nicht, die Übertragung scheint irgendwie Grenzwertig zu sein.

Und jede Art Last auf dem System scheint negativen Einfluss zu haben, mal mehr mal weniger.

Neu ist die Entdeckung, dass man den Fehler mit rsync zuverlässig reproduzieren kann.

Eigentlich müsste man jetzt mal mit einem PCIe-Tester ran und schauen, was da wirklich passiert. Das ist nur leider kein Ding, was man so mal schnell irgendwo ausleihen kann.

Ich weiss nicht, wie das Interesse seitens DD an dem Thema aussieht. Aber DD und Linux4Media waren AFAIK im Münchner Raum ansässig und das Equipment haben sie sicher auch. Vielleicht wollen die sich den Aufbau mal an schauen. Schliesslich laufen ja alle anderen, getesteten PCIe-Karten und Devices auf dem Board fehlerfrei.

Man könnte es noch mal mit Windows versuche, ob da die Karten da besser laufen.

Wenn ja, könnte man das evtl. Treibermässig auf der Seite vom Mainboard was machen.

Argus · 14. April 2019

Zitat von SHF

Ich weiss nicht, wie das Interesse seitens DD an dem Thema aussieht.

darüber hatte ich auch nachgedacht. Ich habe vergeblich gesucht, irgendwelche Fehlermeldungen aus dem Windoswlager zu finden. Das einzigste was ich fand, war das die Karte auf einigen Boards unzuverlässig erkannt wird. Anscheinend gibt es das I2C Problem unter Windows nicht. Auch in den Bedienungsanleitungen zur Max findet sich der Hinweis bei I2C-Timeout zur msi Behandlung unter Linux. Das Thema wird DD nicht unbekannt sein, wird aber vermutlich nur bei Linux auftauchen und wegen dem verhältnismäßig geringen Auftreten auch nicht die Prio haben.

I2C Timeouts mit ddbridge

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema