I2C Timeouts mit ddbridge

  • Sorry, hat etwas gedauert, weil ich erst die Freigabe von DD für die angehängten Bilder erfragen musste.

    Die aktuelle Aussage von DD ist, dass es sicher am HW-Design des ASRock J3455M Motherboards liegt, wie die angehängten Screenshots ihres PCIe-Analyzers zeigen sollen.

    Die Erklärung von DD dazu:

    "Asrock_Crash zeigt ein "Nak" bei dem zuvor keine Datenpakete unterwegs waren. Danach werden Pakete nicht mehr acknowledged " ak" was dann nach kurzer Zeit zum crash führt. Das Zweite Bild Zeit weiter "Naks" die nicht zum Crash führten aber nicht vorkommen dürften. Dem Hersteller muß das Problem bekannt sein, da er das Problem von der 1.4 Firmware bis zur 1.6er Firmware deutlich verbessert hat, aber offensichtlich geht die Lösung nicht weit genug. Wir versuchen gerade herauszufinden was der Hersteller hier geändert hat. Wir nutzen mit der gleiche CPU ein Board von Faytech ( FAY003 gefertigt von ASUS) das ein solches Verhalten nicht aufzeigt."


    Man ist wohl mit ASRock in Kontakt, aber ob sich von deren Seite was tut, ist ungewiss.


    Mit dem J4105M läuft die DD-Hardware dagegen soweit stabil.

  • Moin!

    Ich klinke mich mal ein und bestätige gleiches Problem auf meinem Asrock J3455B-ITX mit der DVB-Max S8/ddbridge.

    ... und bin gespannt auf die Lösung. Mit dem Asrock-Support hatte ich zumindest nur gute Erfahrungen.

  • Interessante Einblicke, danke fürs Teilen.

    - gleichfalls an DD für die Erlaubnis dazu.

    Die aktuelle Aussage von DD ist, dass es sicher am HW-Design des ASRock J3455M Motherboards liegt, wie die angehängten Screenshots ihres PCIe-Analyzers zeigen sollen.

    Für eine Sequenz erst ein "Ack" zu senden und dann später ein "Nak", finde ich auch irgendwie unüblich.

    (Zur genaueren Bewertung müsste ich mich damit aber näher beschäftigen.)


    Nach dem "Nak" hätte ich auch eigentlich eine erneute Übertragung der betroffenen Pakete erwartet. Die findet anscheinend nicht statt.

    Wobei die vor dem "Nak" schon akzeptiert wurden ("Ack"), eventuell liegt es daran.


    Da scheint also irgendwas mit der PCIe-Fehlerbehandlung auf dem Board falsch zu laufen.



    Damit alles auf das Board schieben, macht es sich DD IMHO aber etwas zu einfach.

    Die Datenfehler "CorrErr+" wandern immer mit der DD-Karte, ans andere Mainboard, an den PCIe-Riser, ....

    Da muss also irgendwas nicht 100% sauber laufen (die anderen Karten machen die ja nicht).
    Solange das Fehlerbehandlung klappt, geht die DD-Karte wohl. Erst in Verbindung mit der defekten Fehlerbehandlung wird es dann irgendwann knallen.

    Aber da die anderen PCIe-Karten (Riser, Lan, DVBSky und auch alle meine), es schaffen keine "CorrErr+"-Fehler zu produzieren, sollte man sich überlegen, da auch mal anzusetzen.


    Ohne die"CorrErr+"-Fehler würde DD auch im J3455M laufen, da würde ich drauf wetten. Das ist da wohl einfach ein ungünstiges Zusammentreffen.


    Man ist wohl mit ASRock in Kontakt, aber ob sich von deren Seite was tut, ist ungewiss.


    Vielleicht ist es schon etwas spät, der Nachfolger ist schon raus und das Board ist praktisch im Abverkauf.

    Mal sehen, ich drücke die Daumen.


    Mit dem J4105M läuft die DD-Hardware dagegen soweit stabil.


    Naja, die CorrErr+ hatte die DD-Karte auf dem Board doch auch?

    Gruss
    SHF


  • Naja, die CorrErr+ hatte die DD-Karte auf dem Board doch auch?

    Aber nur auf der "Gegenseite":

  • die CorrErr+ werden ein Indiz aber nicht das Problem sein, denn auf anderen Systemen sind sie auch zu finden ohne zu stören, siehe bsw. hier --> I2C Timeouts mit ddbridge


    es wird schon, so wie von DD vermutet, ein HW Design Fehler vorliegen. Entweder was im Chipsatz und/oder im PCB Layout. Dann wird es wohl auch so sein, das mehrere Parameter sich hier addieren und nicht einer allein ganz "Schuld" trägt. Ich denke da an die Vergangenheit, als Nvidia MBs abgebrannt sind (PCI Slot Leiterbahn), als dort eine bestimmte DVB Budget Karte hinein gesteckt wurde. Dort hatten sowohl MB Hersteller sowie Sat karten Hersteller die Spec. für die Stromversorgung jeweils etwas überreizt und in Summe gab es dann diesen Fehler. Danach hatten dann auch die meisten Sat Karten einen extra Stromanschluß für LNBs.

  • die CorrErr+ werden ein Indiz aber nicht das Problem sein

    Die "CorrErr+"-Flags setzt der Empfänger, wenn er defekte Datenpakete empfängt, die er aber noch korrigieren konnte. (Durch Anforderung einer erneuten Übertragung oder wie auch immer.)

    Erst wenn Korrektur scheitert, wird auch "UnCorr+"-Flag gesetzt.


    Solange also nur "CorrErr+" gesetzt ist, sind die Daten die man bekommt (noch) in Ordnung.


    Trotzdem sind dauernd gesetzte "CorrErr+" ein eindeutiges Indiz, dass die Übertragung nicht "sauber" läuft.


    Und da die "CorrErr+" immer nur in einem Link auftauchen, an dem eine DD-Karte beteiligt ist, kann das eigentlich nur bedeuten, dass die die Ursache ist.


    es wird schon, so wie von DD vermutet, ein HW Design Fehler vorliegen. Entweder was im Chipsatz und/oder im PCB Layout.

    Meine Vermutung geht in Richtung BIOS.


    Am Chipsatz kann es nicht liegen, sonst wären andere Boards mit dem SOC auch betroffen.

    Und was kann man bei 6 Daten-Leitungen gross falsch machen?


    Dann wird es wohl auch so sein, das mehrere Parameter sich hier addieren und nicht einer allein ganz "Schuld" trägt.

    Für mich sieht es so aus:

    Die Karte arbeitet nicht "sauber" und produziert bei der Übertragung Fehler.

    Bei J3455M funktioniert die PCIe-Fehlerkorrektur nicht richtig.

    Trifft beides zusammen knallt's.


    Aber nur auf der "Gegenseite":

    Das "CorrErr+" wird immer vom Empfänger der Daten gesetzt. (Geht ja auch nicht anders, wie sollte der Sender wissen, ob die Übertragung fehlerfrei war.) Über den Verursacher des Fehler sag das überhaupt nichts aus.

    In dem Fall bedeutet das also nur, dass die Fehler in den Daten Richtung Mainboard waren.


    Bei einer DVB-Karte gehen typischer Weise viel mehr Daten von der Karte zum Mainboard, als umgekehrt. Daher ist es auch eigentlich zu erwarten, dass die Fehler häufiger in der Richtung auftreten.


    Hat DD auch diese Karte mit dem PCie Analyzer getestet? Es wäre interessant zu wissen, ob es damit auch diese unerwarteten "Nak"s gibt.

    Das wäre wirklich mal interessant.

    Meine Vermutung ist, die kommen nicht.


    Je öfter ich mir die Bilder ansehe, um so weniger sicher bin ich, ob die "Nak" falsch sind.

    Logischer finde ich inzwischen, dass das "Ack" direkt nach der Übertragung falsch ist. Angenommen in diesem Paket ist ein Fehler oder es ist unvollständig, müsste nach einem Timeout ein "Nak" folgen (und dann einer erneute Übertragung). Wenn in der Zwischenzeit aber schon ein "Ack" gesendet wurde, weiss die Gegenstelle was sie tun soll, weil das nicht dem Standard entspricht.


    Je schneller der Empfänger das "Ack" nach einem Datenpaket zurück schickt, desto eher kann der Sender das nächste Paket schicken. Das Steigert natürlich den Durchsatz.

    Für mich riecht das nach einem experimentellen Feature zur Beschleunigung des PCIe-Durchsatzes, das versehentlich noch aktiviert ist. (VIA lässt grüssen ;).)

    Gruss
    SHF


  • Solange also nur "CorrErr+" gesetzt ist, sind die Daten die man bekommt (noch) in Ordnung.


    Trotzdem sind dauernd gesetzte "CorrErr+" ein eindeutiges Indiz, dass die Übertragung nicht "sauber" läuft.

    mein Reden



    Und was kann man bei 6 Daten-Leitungen gross falsch machen?

    so einiges.

    Ist ja keine Klingelleitung, da geht schon HF drüber. Parasitäre Kapazitäten, Induktivitäten, sonstige passive Komponenten usw können beeinflussen. Beim differentiellem Aderpaar braucht es schon gleiche Quellimpedanz, gleiche Leitungsimpedanz und gleiche Lastimpedanz. Ganz so trivial ist die Geschichte nicht.

    Am Chipsatz kann es nicht liegen, sonst wären andere Boards mit dem SOC auch betroffen.

    wer sagt denn, das dem nicht so ist? Wer hat das in der Tiefe genau analysiert? Selbst hier bei den beiden Asrock PCI-Brigdes sind (laut lspci) nicht identische Controller im Einsatz.

  • [...] Ganz so trivial ist die Geschichte nicht.

    Klar, falsch machen kann man immer was.

    Generell ist PCIe aber wohl deutlich unempfindlicher als PCI.

    So ein 1m "USB3"-Rieserkanel wäre PCI undenkbar.


    Ausserdem gibt es bei PCIe x1 nur ein Aderpaar je Richtung.

    Wenn da irgendwas falsch läuft muss es eigentlich alle Übertragungen betreffen.


    wer sagt denn, das dem nicht so ist? Wer hat das in der Tiefe genau analysiert?

    Wir nutzen mit der gleiche CPU ein Board von Faytech ( FAY003 gefertigt von ASUS) das ein solches Verhalten nicht aufzeigt.


    Selbst hier bei den beiden Asrock PCI-Brigdes sind (laut lspci) nicht identische Controller im Einsatz.

    Laut meinen Informationen (man korrigiere mich, wenn ich falsch liege), ist die PCIe-Hostbridge Teil des J3455 SOC.

    D.h. alle Boards mit dem Celeron J3455 haben die gleiche.

    Gruss
    SHF


  • Gibt es eine Reaktion von Asrock? Sollte jeder von uns den Support mit dem Problem anschreiben, um etwas Druck aufzubauen?

  • Ich hänge mich auch mal mit dran - habe das Problem mit einer Cine S2 6.5 in einem HP Microserver Gen 10.

    Das Problem (timeout) zeigt sich schon direkt beim Module-Load (bzw. sofort wenn tvheadend gestartet wurde)

    Treiber ist der 0.9.36 von https://github.com/DigitalDevices/dddvb/releases.
    Strom ist angeschlossen, in einem anderen Rechner funktionierte die Karte vorher Problemlos...

  • Eigentlich sieht es immer noch so aus, als ob sowohl Mainboard als auch TV-Kartenhersteller nicht ganz standard-konforme Komponenten designed haben. Und nun gegenseitig aufeinander zeigen als den Schuldigen.