Interessant waere auch, ob es irgendwo "transfer error" oder "NAK" Meldungen gibt, aber sonst keine Probleme beim Empfang.
Gruss,
S:oren
Interessant waere auch, ob es irgendwo "transfer error" oder "NAK" Meldungen gibt, aber sonst keine Probleme beim Empfang.
Gruss,
S:oren
Baut gerade mit fix2.
Interessant waere auch, ob es irgendwo "transfer error" oder "NAK" Meldungen gibt, aber sonst keine Probleme beim Empfang.
Das werde ich beobachten.
Grüße
kamel5
Jetzt hatte ich schon mal ein einzelnes "NAK":
Mär 16 12:03:45 home-05.home.de kernel: SAA716x FF 0000:0c:00.0: I2C 1 read NAK, msg 1, addr = 0x68, len=1
Sonst keine Auffälligkeiten und die beiden Tuner sind noch aktiv.
Grüße
kamel5
Hier noch ein paar "NAK" ab 12:26:13.
Die Tuner sind immer noch aktiv.
Keine Auffälligkeiten dazu im vdr-Log.
Das beigefügte Log ist die Fortsetzung des vorherigen.
Grüße
kamel5
Alle bei verschiedenen Registern. Am I2C-Gate selber liegt es also nicht. Hm.
Gruß,
Sören
Hier nochmal einige "NAK".
Beide Tuner immer noch am Leben und keine weiteren Auffälligkeiten.
Grüße
kamel5
Hier noch ein Log.
Diesmal nach dem NAK um 15:10:13 und 15:10:58 ein "frontend 0/0 lost lock" mit folgendem "frontend 0/0 regained lock".
Beide Tuner gehen immer noch.
Grüße
kamel5
Da hat es wohl zufällig das Lesen des Lock-Registers getroffen. Da scheint mir ansonsten kein Muster drin zu sein. Irgendwelche Reads gehen gelegentlich schief.
Nach I2C-Spec braucht man eigentlich keine lange Wartezeit vor dem Read. Vielleicht braucht der Demod das?
Hat irgendwer ein Datenblatt und/oder User-Manual von dem stv0900?
Gruß,
Sören
Hat irgendwer ein Datenblatt und/oder User-Manual von dem stv0900?
Ich meine natuerlich nicht diese 5 Seiten Overview...
Jetzt ist bei mir auch mal so ein NAK aufgetreten, aber auf dem Tuner (Adresse 0x60), nicht auf dem Demod (0x68). Also liegt es auch nicht an einer eventuell komischen Demod-I2C-Implementierung.
Ich habe jetzt die Logs seit gestern nochmal durchgesehen und keine weiteren Fehlermeldungen außer den "NAK" gefunden.
Im Moment sieht es so aus, das diese "NAK"s auch keine offensichtlichen Auswirkungen haben. Die Tuner scheinen auch damit ohne Probleme zu funktionieren.
Ich werde das die nächste Zeit weiter beobachten und mich melden, wenn sich da eine Änderung ergibt.
Grüße
kamel5
Danke!
Ich hatte nochmal mit Wartezeiten zwischen den Transfers probiert, das hilft nicht. Ich hoffe, ich finde noch eine bessere Loesung.
Im Moment scheinen die NAKs (nach I2C Spec NACKs, soll ich das umbenennen?) nicht wirklich echt zu sein. Immerhin wird jetzt eine Null statt nicht-initialisierten Daten zurueckgegeben, dadurch laeuft es etwas besser, aber richtig gut und vertrauenerweckend ist das so noch nicht.
Gruss,
S:oren
(nach I2C Spec NACKs, soll ich das umbenennen?)
Warum nicht? "NAK" habe ich nur in einer Zeile gefunden oder habe ich da was übersehen.
Und dann ist es richtiger...
Grüße
kamel5
Naja, so lange hat es doch nicht gehalten...
Nachdem 2 Aufnahmen auf der TT6400 (Tuner1 und 2) beendet wurden und Live-TV von Tuner 3 wieder zurück zu Tuner 1 ging, gab es wieder einen Ausfall von Tuner 2.
In den Logs so ab 17:23.
In der SAA716x-12a.txt.gz sind als Übersicht nur die "NAK"s drin.
Grüße
kamel5
Ist das wirklich die letzte Codeversion? Hier wird wieder Unsinn in das I2C-Gate-Register geschrieben.
Mär 17 17:24:25 kernel: SAA716x FF 0000:0c:00.0: I2C 1 write transfer, addr=0x68 length=2
Mär 17 17:24:25 kernel: SAA716x FF 0000:0c:00.0: <W 0000> 0xf1
Mär 17 17:24:25 kernel: SAA716x FF 0000:0c:00.0: <W 0001> 0x2b
Mär 17 17:24:25 kernel: SAA716x FF 0000:0c:00.0: I2C 1 read transfer, addr=0x68 length=1
Mär 17 17:24:25 kernel: SAA716x FF 0000:0c:00.0: I2C 1 read NAK, msg 1, addr = 0x68, len=1
Mär 17 17:24:25 kernel: SAA716x FF 0000:0c:00.0: I2C 1 write transfer, addr=0x68 length=3
Mär 17 17:24:25 kernel: SAA716x FF 0000:0c:00.0: <W 0000> 0xf1
Mär 17 17:24:25 kernel: SAA716x FF 0000:0c:00.0: <W 0001> 0x2b
Mär 17 17:24:25 kernel: SAA716x FF 0000:0c:00.0: <W 0002> 0x7a
Gruß,
Sören
Mist, Du hast recht.
Da scheint beim Umkopieren etwas durcheinander gekommen zu sein.
Ich mache das nochmal neu...
Bitte den vorletzten Post ignorieren.
Grüße
kamel5
Vielleicht kannst Du gleich meinen aktuellen Testcode nehmen. Der lief jetzt eine Weile bei mir. Aber so ein Fehler kommt bei mir erst nach Stunden.
Die NACKs sind umbenannt.
Gruß,
Sören
Mache ich, aber erst morgen in aller Ruhe.
Im Moment bin ich mir gar nicht mehr so sicher, das das letzte Log mit dem falschen Treiber entstanden ist.
Es ist ja vorher auch über 7h ohne Probleme gegangen. Ich werde das auch morgen noch mal prüfen.
Grüße
kamel5
Das hat mir jetzt doch keine Ruhe gelassen. Die "NAK"-Meldungen gibt es ja erst seit fix2, also sollten diese Logs auch mit dem letzten Treiber-Stand entstanden sein. Nicht gut, oder.
Grüße
kamel5
Hm, verstehe ich nicht. In fix2 werden die Read-Daten bei NAK genullt.
Aber eigentlich sollten diese NAK gar nicht vorkommen (mit vdr, mit i2c_detect schon). Vielleicht klappt es mit fix3 besser?
Gruß,
Sören
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!