Nee, hilft auch nicht wirklich. Ohne viele Debug-Meldungen (nur das NACK) passiert es doch wieder. Also doch ein Timing-Problem!?
Gruß,
Sören
Nee, hilft auch nicht wirklich. Ohne viele Debug-Meldungen (nur das NACK) passiert es doch wieder. Also doch ein Timing-Problem!?
Gruß,
Sören
Ich habe meine Sicherungen nochmal durchgesehen und ja, die Logs aus Post #34 waren mit fix2.
Ab jetzt teste ich mit fix3.
Ich habe auch nochmal überlegt, warum ich so viel mehr alte "NAK"s bekommen habe. Am VDR selber kann es ja eigentlich nicht liegen. Aber ich nutze hier beide Tuner immer im Transfer Mode.
Wenn ich das richtig verstanden habe, werden bei unverschlüsselten Sendern die Videodaten direkt auf der Karte zum Ausgabedevice durchgereicht. Bei mir werden die Videodaten aber immer über den VDR geleitet, also 2x über den PCI-Bus. Deshalb vielleicht auch die größere Fehlerhäufigkeit bei einer zusätzlichen Aufnahme auf dem 2. Tuner.
Du könntest mal testen, ob sich die Fehlerhäufigkeit bei Dir erhöht, wenn Du beide Tuner mit einer Aufnahme belegst und damit den Transfermode auch auf Tuner 1 erzwingst.
Grüße
kamel5
Transfermode betrifft ja nur die TS-Daten. Die Einstellungen und Abfragen von Tuner und Demod ueber I2C sind komplett unabhaengig davon, wie die TS-Daten weiterverarbeitet werden.
Nach meiner letzten Theorie handelt es sich doch um ein Timing-Problem. Eine signifikante Wartezeit zwischen Setzen der Leseadresse und dem eigentlichen Lesen scheint die Wahrscheinlichkeit fuer so ein NACK zu verringern. Vermutlich ist diese Zeit bei mir auf den armv7 / armv8-Systemen (i.MX6Q / RK3399 mit PCIe-Switch) generell etwas größer als auf Deinem Ryzen7.
Jedenfalls habe ich keine Abhaengigkeit von Aufnahmen oder Tunernummer feststellen koennen. Aber die Statistik ist natuerlich schlecht bei einem NACK alle paar Stunden...
Grüße,
Sören
Aber die Statistik ist natuerlich schlecht bei einem NACK alle paar Stunden...
Nützt es Dir was, wenn ich Dir die NACK häufiger schicke oder soll ich die eher sammeln?
Im Moment habe ich schon wieder 2 seit dem Rechnerstart vor reichlich einer Stunde.
Nach meiner letzten Theorie handelt es sich doch um ein Timing-Problem.
Gibt es da einen Parameter, an dem ich hier vorsichtig mal Änderungen vornehmen könnte, um zu sehen, ob sich da bei mir was ändert?
Grüße
kamel5
Warum nicht einfach bei jedem NAck mitloggen und automatisch die Zeitkonstante erhöhen mit print ins log?
Nützt es Dir was, wenn ich Dir die NACK häufiger schicke oder soll ich die eher sammeln?
Ich meine, die NACK bei mir treten nur alle paar Stunden auf.
Deine NACKs haben sehr geholfen festzustellen, dass die bei beliebigen Adressen auftreten und nicht an das I2C-Gate gekoppelt sind (dort nur besonders fatale Auswirkungen haben wenn Unsinn zurueckgeschrieben wird). Im Moment versuche ich, eine Einstellung zu finden, wo gar keine NACKs mehr bei vdr-Betrieb auftreten.
Ich brauche im Moment nicht mehr die vollstaendigen Logs, nur die Information ob NACKs auftreten. Trotzdem nochmal Danke fuer Deine Bemuehungen.
Gibt es da einen Parameter, an dem ich hier vorsichtig mal Änderungen vornehmen könnte, um zu sehen, ob sich da bei mir was ändert?
In dem fix3 gibt es
Das wieder einkommentieren. Mit einer Range (100, 120) sieht es bei mir gerade recht gut aus.
Danke,
Sören
OK, das probiere ich aus.
Grüße
kamel5
So ein Hack ist irgendwie unbefriedigend, weil es keine Erklaerung fuer die Wartezeit gibt. Einen anderen Fehler habe ich aber auch nicht finden koennen (z.B. Probleme mit I2C_SDA_HOLD).
Alternativ koennte man ueberlegen, doch wieder so einen Retry-Mechanismus einzubauen, wie es im alten Treiber war. Hier wurden Transfers bis zu 2x wiederholt, wenn etwas schief gegangen ist. Sowas koennte aber auch an sich Probleme mit manchen I2C-Slaves verursachen.
Langsam gehen mir die Ideen aus...
Gruss,
S:oren
Verstehe, eine saubere Lösung ist natürlich immer besser.
Ich werde das mal ausprobieren mit der Wartezeit. Und wenn das hilft findet sich vielleicht auch noch die Lösung dafür...
Grüße
kamel5
Interessant ist auch, dass ich keinen Unterschied feststellen kann, egal ob der I2C-Bus mit 100 oder 400kHz betrieben wird.
Gruß,
Sören
Es läuft jetzt bei mir mit der Wartezeit.
Ich melde mich sobald sich ein NACK zeigt.
Grüße
kamel5
Vorsichtiger Optimismus...
Das Ganze läuft jetzt seit ca 12:50 mit aktivierter Wartezeit und bisher sind keine "NACK"s aufgetreten.
Grüße
kamel5
Ich will mal eine positive Rückmeldung geben.
Seit dem ich gestern die Wartezeit aktiviert habe, hatte ich bis jetzt keinerlei Fehlermeldungen mehr.
Auch sonstige Instabilitäten konnte ich nicht feststellen.
Grüße
kamel5
Sehr schoen, sowas hoert man gerne.
Da lohnt es sich doch, wieder ein paar Patches fertig zu machen, immerhin steht 5.17 an.
Sollen der 5.16er Branch stabil bleiben, oder kann ich Fixes von Fixes zusammenfassen?
Gruß,
Sören
Ich würde die Fixe zusammenfassen. Und den 5.16er Branch noch auf einen funktionierenden Stand bringen, man weiß ja nie, wer den mal einsetzen will, gern auch mit der Wartezeit (solange es nichts besseres gibt).
Grüße
kamel5
Ich glaube zu wissen, was das Problem ist. Es gibt keine Moeglichkeit festzustellen, wann ein Byte ueber I2C fertig uebertragen wurde. Im Treiber kann ich nur sehen, wann mit der Uebertragung begonnen wurde, das ACK-Bit kommt irgendwann spaeter (und damit das NACK-Flag, oder eben nicht).
Wie kann man nur eine derartig unsinnige Hardware bauen!
Gruss,
S:oren
Hier nochmal eine neue Version zum Testen. Das ergibt so fuer mich Sinn, so gut es eben mit dieser "merkwuerdigen" Hardware geht.
Gruss,
S:oren
Da hast Du dann wohl doch noch eine bessere Lösung gefunden.
Es läuft jetzt bei mir seit einer 1/2 Stunde mit fix4. Bis jetzt noch keine Auffälligkeiten.
Ich werde das wieder bis morgen durchlaufen lassen und dann berichten.
Grüße
kamel5
Ich habe noch ein paar kleinere Verbesserungen angebracht.
Die Wartezeiten werden jetzt in Abhaengigkeit des I2C-Taktes gesetzt und dadurch besser angepasst, damit man moeglichst nicht zu lange wartet, aber auch nicht zu viele kurze Wartepausen nacheinander einlegt. Auch kann die Wartezeit ganz am Ende eines Write-Transfers etwas reduziert werden, wenn man hier speziell auf das Ende der Transaktion (I2C-STOP) wartet.
Fix4 wurde ja schon recht oft heruntergeladen, danke an alle fuer's Testen! Trotzdem hier noch eine weitere Version, das soll jetzt wirklich die (vorerst) letzte sein.
Gruss,
S:oren
Ich habe ab jetzt fix5 aktiv.
Mit fix4 gab es bis eben keine Auffälligkeiten.
Grüße
kamel5
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!