I2C Timeouts mit ddbridge

  • Mit einem ASRock J4105M Motherboard sieht lspci so aus:

    Trotz stundenlangem rsync und (zeitweise) mehreren parallelen Aufnahmen sind im Test an 01:00.0 (Cine V7A) zu keiner Zeit CorrErr+ aufgetreten.

    An der Gegenstation 00:13.0 traten gelegentlich (Abstände in der Größenordnung von Minuten) CorrErr+ auf.

    Insgesamt verlief der Test ohne Probleme.


    Ich habe dieses Board jetzt in meinen Wohnzimmer-VDR eingebaut und werde jetzt noch die Langzeitstabilität beobachten.

  • Ich denke, es ist schwierig, auf einen "Schuldigen" zu zeigen. Manchmal sind zwei Komponenten einfach nicht so richtig kompatibel, auch wenn sie sich an Spezifikationen halten. Bei Mainboards & RAM gibt es genauso Kombinationen, die es theoretisch tun sollen, aber eben nicht immer laufen.

    Deshalb schaue ich immer in die Kompatibilitätslisten der Hersteller.


    Nützt natürlich nichts bei sowas exotischem wie einer DVB-Karte.

  • Mit einem ASRock J4105M Motherboard sieht lspci so aus:

    verbose Level 2 würde mehr Details bringen.


    Wenn ich an meinem alten Streamserver das eingebe:


    kann ich mehr erfahren


    wenn Du das mal mit und ohne Extension Bord machen könntest, dann könnte man die angezeigten Parameter direkt vergleichen. Vielleicht ändert sich ein oder mehrere Parameter und weisen auf das Problem hin.

  • Manchmal sind zwei Komponenten einfach nicht so richtig kompatibel, auch wenn sie sich an Spezifikationen halten.

    zudem könnte auch noch das BS mit ins Spiel kommen, wenn es unter Windows hier nirgendwo Probleme gibt. Das mit dem Windows müsste jemand verifizieren, der auch diese Probleme hat und mit winzigweich kann

  • Ich habe dieses Board jetzt in meinen Wohnzimmer-VDR eingebaut und werde jetzt noch die Langzeitstabilität beobachten.

    Solange CorrErr+ im Rahmen bleiben, wird es wohl gehen.

    Nach dem Aufwand wäre es dir zu wünschen, dass es endlich klappt. Ich drücke jedenfalls mal die Daumen!



    Argus :

    Deine Vermutung war prinzipiell richtig, mein Beitrag war lediglich als Ergänzung der technischen Details gedacht.


    Ich denke, es ist schwierig, auf einen "Schuldigen" zu zeigen.

    Die CoerErr Fehler sind immer in dem Link, an dem die Cine beteiligt ist und auch nur da.

    Völlig unabhängig, welches Gegenüber: Asrock J3355M, PCIe Extension Board, ASRock J4105M immer bilden Fehler und Karte eine Einheit.

    Sogar im lspci -vv Auszug von Argus sind CorrErr+ UncorrErr+ gesetzt!

    Für mich ist das eindeutig genug.


    zudem könnte auch noch das BS mit ins Spiel kommen, wenn es unter Windows hier nirgendwo Probleme gibt. Das mit dem Windows müsste jemand verifizieren, der auch diese Probleme hat und mit winzigweich kann

    Hatte ich auch schon vorgeschlagen.

    Ich habe halt weder so eine Karte, noch wirklich Ahnung von Windows.


    Ich wüsste nicht mal, wie man an die CoerErr-Geschichte da auslesen kann und ob das überhaupt geht.

    Der normale User wird von dem Fehler jedenfalls nichts mit bekommen, solange die Karte nicht komplett aussteigt. Da dazu anscheinend schon einige Faktoren zusammenkommen müssen, ist nicht gesagt, dass es überhaupt auffällt.



    Alternativ könnte man auch mal unter Linux Daten sammel gehen.

    Errorcounter löschen ein Stündchen Fernsehen und dann mitlspci -vv auslesen.
    CorrErr+ UncorrErr+ sollten dann nicht gesetzt sein, bei keiner PCIe-Karte.


    Da CorrErr+ UncorrErr+ auch bei Arguslspci -vv Auszug gesetzt waren, vermute ich, dass das auf mehr Mainboards auftritt als bisher vermutet.

    Mit mehr Daten könnte man zwar Linux als Ursachen nicht ausschliessen, aber abschätzen, wie weit das Problem verbreitet ist.

    Gruss
    SHF


  • Ich habe dieses Board jetzt in meinen Wohnzimmer-VDR eingebaut und werde jetzt noch die Langzeitstabilität beobachten.

    (etwas Off-Topic, Sorry...)
    Verwendest Du auch den HDMI Port von dem Board?
    Bei mir bleibt das Bild (zumindest unter MLD) schwarz - und laut MLD Forum ist das für eine HD600 auch zu erwarten.

    Was für ein Ausgabe-Device verwendest Du?

    Besten Dank!

    Yavdr auf Yammy / 2 Kabel Empfänger / Asrock j4105-itx / IRMP KDB


  • Da CorrErr+ UncorrErr+ auch bei Arguslspci -vv Auszug gesetzt waren, vermute ich, dass das auf mehr Mainboards auftritt als bisher vermutet.

    da es aber im praktischen Betrieb keine Probleme gibt ist die Frage, ab wann es problematisch wird. Ein detektierter Fehler der das Flag setzt, wird nicht das Problem sein. Hier sind diese Fehler auch bekannt --> https://www.kernel.org/doc/Doc…ion/PCI/pcieaer-howto.txt und wohl üblich.

  • Verwendest Du auch den HDMI Port von dem Board?

    Ja, das war mit ein Grund dafür, warum ich diese Art von Board gewählt habe.

    Bei mir bleibt das Bild (zumindest unter MLD) schwarz - und laut MLD Forum ist das für eine HD600 auch zu erwarten.

    Was für ein Ausgabe-Device verwendest Du?

    MLD hatte ich auch mal kurz probiert, konnte damit aber auch keine Ausgabe erreichen.


    Für die Ausgabe verwende ich das vaapidevice-Plugin von https://github.com/rofafor/vdr-plugin-vaapidevice.

    Das hat zwar noch ein paar kleine Macken, ist aber meines Erachtens durchaus schon alltagstauglich.

  • verbose Level 2 würde mehr Details bringen.

    ...

    wenn Du das mal mit und ohne Extension Bord machen könntest, dann könnte man die angezeigten Parameter direkt vergleichen. Vielleicht ändert sich ein oder mehrere Parameter und weisen auf das Problem hin.

    Ohne Riser-Card:

    lspci -s 02:00.0 -vv:

    lspci -s 00:13.0 -vv:

  • Mit Riser-Card:

    lspci -s 04:00.0 -vv:

    lspci -s 03:01.0 -vv:

  • danke,


    ich habe mal mit diff verglichen:


    zuerst die DD

    dort ändert sich nicht viel, außer Interrupt und Fehlerstatus:




    Code
    6c6
    <         Interrupt: pin A routed to IRQ 20
    ---
    >         Interrupt: pin A routed to IRQ 23
    19c19
    <                 DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
    ---
    >                 DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-


    an dem gegenüber aber so einiges:


    neben den unterschiedlichen devices auch max payload, linkspeed, Powerlimit, devcap, linkctl, usw.


    man müsste jetzt mal untersuchen, inwieweit die Abweichungen für gut und böse zuständig sind.

  • Ich habe jetzt noch eine DVBSky S952 V3, mit der ich gerne einen Versuch machen würde.

    Der Treiber hierfür soll ja im Kernel 4.12 enthalten sein. Die nötige Firmware habe ich von http://dvbsky.net/Support_linux.html geholt (http://dvbsky.net/download/linux/firmware.zip) und nach /lib/firmware kopiert. Mir ist aber nicht klar, welche Module ich für die Karte laden muss. Nach einem Neuboot ist zumindest noch kein /dev/dvb vorhanden.

    lspci sagt

    02:00.0 Multimedia video controller: Spin Master Ltd. PCIe Video Bridge (rev 01)

    Kann mir da jemand helfen?

  • hier steht, dass die Firmware für den open source driver != closed source driver ist. https://github.com/OpenELEC/dv…re/dvb-demod-m88rs6000.fw


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • hier steht, dass die Firmware für den open source driver != closed source driver ist. https://github.com/OpenELEC/dv…re/dvb-demod-m88rs6000.fw

    Diese FW ist genau die gleiche wie die, die ich zuerst geholt hatte.


    Es scheint aber ein anderes Problem zu sein:


    [ 8.830709] smipcie: disagrees about version of symbol dvb_dmxdev_init

    [ 8.830712] smipcie: Unknown symbol dvb_dmxdev_init (err -22)

    [ 8.830845] smipcie: disagrees about version of symbol dvb_dmxdev_release

    [ 8.830847] smipcie: Unknown symbol dvb_dmxdev_release (err -22)

    [ 8.830856] smipcie: disagrees about version of symbol dvb_frontend_detach

    [ 8.830857] smipcie: Unknown symbol dvb_frontend_detach (err -22)

    [ 8.830866] smipcie: disagrees about version of symbol dvb_unregister_frontend

    [ 8.830867] smipcie: Unknown symbol dvb_unregister_frontend (err -22)

    [ 8.830870] smipcie: disagrees about version of symbol dvb_register_frontend

    [ 8.830872] smipcie: Unknown symbol dvb_register_frontend (err -22)


    Er will anscheinend durchaus den passenden Treiber automatisch beim Booten laden, aber es passt ihm etwas nicht mit den Symbolen.

    Alle Kernel-Module stammen aber aus der installierten Kernel-Version, und den Eintrag "search extra updates weak-updates kgraft built-in" in /etc/depmod.d/00-system.conf, der für den DD-Treiber nötig ist, habe ich wieder in "search updates extra weak-updates kgraft built-in" zurückgeändert und "depmod -a" gemacht.

    Was mache ich falsch?

Jetzt mitmachen!

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