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.

    Zitat von kls

    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.


    Zitat von kls

    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.


    Zitat von kls

    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


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

    Zitat von Argus

    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.


    Zitat von Argus

    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?


    Zitat von Argus

    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.


    Zitat von kls

    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.


    Zitat von HelmutB

    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


    Zitat von 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



    Zitat von SHF

    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.

    Zitat von SHF

    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.

    Zitat von Argus

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


    Zitat von Argus

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

    Zitat von kls

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


    Zitat von Argus

    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.

    Danke kls für Deine Hartnäckigkeit,


    habe auch das I2C-Timeout-Problem mit DD Cine S2 V7A 0.9.36,

    wie in Deinem spannenden Blog beschrieben.


    Bei mir ist der Fehler häufiger beim Programmwechsel passiert,

    selten auch ohne Zutun und ohne großen Netzwerk-Traffic.


    Nun Update auf Version 0.9.37 durchgeführt, mal schauen...

    offenbar werden unter der Version 0.9.37 permanent Aktualisierungen eingefügt,

    https://github.com/DigitalDevi…b/compare/0.9.36...0.9.37


    Das System scheint nun stabil zu laufen,

    selbst nach Stunden und sehr häufigen Programmwechsel hängt sich die Karte nicht weg.

    Mein System:

    ASROCK J3455 BIOS:1.80 OpenSuse Leap 15.1 4.12.14 KDE Kaffeine

    DD Cine S2 V7A

    DiSEqC Motor GT-DM14MG

    60cm Offset

    FTE eXcellento HQ Single LNB

    Muss mich leider korrigieren,


    hatte gerade zufällig auf ProSieben Schweiz ausgewählt, Karte hängt :(


    [ 9667.454565] ddbridge 0000:04:00.0: I2C timeout, card 0, port 0, link 0

    [ 9667.454570] ddbridge 0000:04:00.0: DDBridge IRS 00000000

    [ 9667.454573] ddbridge 0000:04:00.0: I2C cmd=0000d001 mon=0802000f

    [ 9668.478549] ddbridge 0000:04:00.0: I2C timeout, card 0, port 0, link 0

    [ 9668.478554] ddbridge 0000:04:00.0: DDBridge IRS 00000001


    ...


    [ 9685.886626] ddbridge 0000:04:00.0: I2C timeout, card 0, port 0, link 0

    [ 9685.886632] ddbridge 0000:04:00.0: DDBridge IRS 00000001

    [ 9685.886634] lnbh25: i2c_write error

    [ 9686.910625] ddbridge 0000:04:00.0: I2C timeout, card 0, port 0, link 0

    [ 9686.910630] ddbridge 0000:04:00.0: DDBridge IRS 00000001


    ...


    [ 9809.791103] ddbridge 0000:04:00.0: I2C timeout, card 0, port 0, link 0

    [ 9809.791109] ddbridge 0000:04:00.0: DDBridge IRS 00000001

    Mal eine ganz "blöde" Frage - habt Ihr schon mal an's Netzteil bzw. die Stromversorgung der Karte (via PCIe-Bus) gedacht? Kann man da Probleme ausschließen - bevor hier der gesamte PCIe Stack analysiert und zerpflückt wird und das ganze nur an einer etwas schwachbrüstigen oder verbrummten/ verrauschten Stromversorgung (altes Netzteil?) oder ungünstiger PCIe Slot mit den längsten Signalwegen liegt? Evtl. mal Brummspannungen messen, einmal am Netzteil und andererseits auf der Karte


    Falls mit Oszilloskop gearbeitet wird braucht ihr aber auf alle Fälle einen Trennstransformator, da das Oszilloskop auf der GND-Seite mit dem Erder der Stromversorgung verbunden ist und der Rechner bzw. auch die SAT-/ Antennenanlage jeweils ebenfalls einseitig geerdet ist und sich ansonsten eine Erdschleife/ Brummschleife bildet.

    Mal ne ganz blöde Antwort... jetzt wo du es fragst... ne ist noch keiner drauf gekommen die Spannungsversorgung auszuschließen. :S

    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)


    Ohne jetzt alles gelesen zu haben...

    Die Max S8 macht das auch. Ist in meinem Fujitsu W530 "Server" nicht nutzbar.

    Obwohl ich es eigentlich nicht wollte, habe ich ein Octopus-Net_Rack gekauft und auf SatIP umgestellt.


    Gruß Jan

    1:Dell PoweEdge T20; Xeon E3-1225 v3; 32GB RAM; Proxmox 5.4; MLD 5.4 als VDR-Server; 2 x Cine S2;
    2:Intel NUC i3 Passiv; 4GB RAM; 120GB SSD; easyvdr 3.5 als client; Harmony Hub

    2:Intel NUC i5 Passiv; 4GB RAM; 120GB SSD; easyvdr 3.5 als client; Harmony Hub
    3:Raspberry Pi 3B; MLD

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden