Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

Zitat von nst

War anschliessend auch der Port an der Karte angeblich nicht belegt?

Kann ich leider nicht sagen, da ich danach nicht mehr versucht habe, den Treiber neuzuladen.

Zitat von nst

Die Problem(chen) scheinen irgendwie nicht wirklich reproduzierbar zu sein. Ich habe alleine heute bestimmt schon 3x die Kernelmodule zwecks Tests ent- und neu geladen, keine Probleme... Ich vermute, dass entweder der Demod in einem "komischen" Zustand ist, während er initialisiert wird (und sich im Anschluss einfach komplett aufhängt), oder der I2C Code in ddbridge die Ports etwas "kräftiger" resetten könnte. Beides sind aber Dinge, die sich gerne jemand anderes anschauen darf

Ich konnte das Problem heute auch nicht noch mal reproduzieren, obwohl ich 20x hintereinander den Treiber in kurzer Abfolge entladen und wieder neu geladen habe. Ist für mich aber auch kein Showstopper, da das Problem bei normaler Nutzung selten auftreten sollte. Ich weiß außerdem gar nicht, ob man es ganz verhindern kann. Selbst mit dem DD-Treibern aus media_build_experimental von UFO habe ich schon I2C-Fehler gesehen, wenn auch sehr selten. Etwas ärgerlich an der Sache ist nur, daß ein Reboot bei einem Fehler nicht hilft und man den VDR ganz ausschalten muß.

Zitat von gentoo-vdr

Ich konnte das Problem heute auch nicht noch mal reproduzieren, obwohl ich 20x hintereinander den Treiber in kurzer Abfolge entladen und wieder neu geladen habe. Ist für mich aber auch kein Showstopper, da das Problem bei normaler Nutzung selten auftreten sollte. Ich weiß außerdem gar nicht, ob man es ganz verhindern kann. Selbst mit dem DD-Treibern aus media_build_experimental von UFO habe ich schon I2C-Fehler gesehen, wenn auch sehr selten. Etwas ärgerlich an der Sache ist nur, daß ein Reboot bei einem Fehler nicht hilft und man den VDR ganz ausschalten muß.

Wenn das Problem nicht irgendwo aus Fehlern in ddbridge-i2c.c oder stv0367dd.c resultiert, dürfte das fast ein Hardware- oder -designproblem sein, dagegen macht man nicht viel

Ich habe heute mal ein bisschen den stv0367dd refaktoriert: Neben einigen derzeit noch überschaubaren Aufräumarbeiten (ähnlich wie im cxd2843 Modul) ist die Kernellog-Ausgabe jetzt etwas hübscher, i2c_write Fehler werden mit Register und erstem Datenbyte berichtet, und i2c_read-Fehler werden überhaupt jetzt reported (nichts von beiden sollte je auftreten, aber evtl. kann man etwas daraus ableiten, falls beim Init nochmal Probleme auftreten). Ausserdem werden Dinge wie SNR (funktioniert mit dem Demod jetzt! ) und Bitfehlerrate jetzt in DVBv5 API-Struktur ausgegeben. Magst Du (bzw. alle mit CineCTv6 oder DuoFlex CT "ohne 2") das mal Testen? Der Code bzw. die Commits sind im mediatree/master-ddbridge-testing-Branch zu finden. Interessant wäre vor allem, ob und wie VDR damit (APIv5) umgeht (TVHeadend zeigt SNR brav als dB-Wert an, Signalstärke funktioniert mangels Implementierung derzeit nicht), und natürlich, obs damit jetzt Probleme gibt.

Zitat von nst

Ich habe heute mal ein bisschen den stv0367dd refaktoriert: Neben einigen derzeit noch überschaubaren Aufräumarbeiten (ähnlich wie im cxd2843 Modul) ist die Kernellog-Ausgabe jetzt etwas hübscher, i2c_write Fehler werden mit Register und erstem Datenbyte berichtet, und i2c_read-Fehler werden überhaupt jetzt reported (nichts von beiden sollte je auftreten, aber evtl. kann man etwas daraus ableiten, falls beim Init nochmal Probleme auftreten). Ausserdem werden Dinge wie SNR (funktioniert mit dem Demod jetzt! ) und Bitfehlerrate jetzt in DVBv5 API-Struktur ausgegeben. Magst Du (bzw. alle mit CineCTv6 oder DuoFlex CT "ohne 2") das mal Testen? Der Code bzw. die Commits sind im mediatree/master-ddbridge-testing-Branch zu finden. Interessant wäre vor allem, ob und wie VDR damit (APIv5) umgeht (TVHeadend zeigt SNR brav als dB-Wert an, Signalstärke funktioniert mangels Implementierung derzeit nicht), und natürlich, obs damit jetzt Probleme gibt.

Klar, hier das Kernellog:

[    4.757847] Digital Devices PCIE bridge driver 0.9.22, Copyright (C) 2010-15 Digital Devices GmbH
[    4.758113] DDBridge driver detected: Digital Devices DVBCT V6.1 DVB adapter
[    4.758142] DDBridge: HW 00010007 REGMAP 00010003
[    4.758283] DDBridge: using 1 MSI interrupt(s)
[    4.760274] Port 0: Link 0, Link Port 0 (TAB 1): DUAL DVB-C/T
[    4.761281] Port 1: Link 0, Link Port 1 (TAB 2): NO MODULE
[    4.762296] Port 2: Link 0, Link Port 2 (TAB 3): NO MODULE
[    4.762700] DVB: registering new adapter (DDBridge)
[    4.762704] DVB: registering new adapter (DDBridge)
[    4.785947] stv0367dd: STV0367 DVB-C DVB-T demod with ChipID 60 found at adr 1F on i2c-7
[    5.074831] tda18212 7-0060: NXP TDA18212HN/M successfully identified
[    5.074849] ddbridge 0000:05:00.0: DVB: registering adapter 0 frontend 0 (STV0367 DVB-C DVB-T)...
[    5.076104] stv0367dd: STV0367 DVB-C DVB-T demod with ChipID 60 found at adr 1E on i2c-7
[    5.350932] tda18212 7-0063: NXP TDA18212HN/S successfully identified
[    5.350954] ddbridge 0000:05:00.0: DVB: registering adapter 1 frontend 0 (STV0367 DVB-C DVB-T)...

VDR (Version 2.2.0) funktioniert und zeigt mir für das SNR einen vollen Balken an (vorher nur ein kleiner Strich), in femon steht bei STR, SNR, BER und UNC nun aber gar nichts mehr. STR zeigte zuvor immer 0%, SNR war zwar auch 0%, aber dort hatte ich immerhin Hex-Werte, die bei der Beurteilung der Signalqualität halfen.
Kann es evtl. auch an femon liegen, daß mir nichts angezeigt wird? Ich verwende noch die etwas ältere Version 2.0.4.
EDIT: Auch mit vdr-femon-2.2.1 werden mir keine Signalinformationen angezeigt.

Leider hatte ich vorhin direkt nach dem Reboot wieder I2C-Fehler:

[    4.645434] Digital Devices PCIE bridge driver 0.9.22, Copyright (C) 2010-15 Digital Devices GmbH
[    4.645717] DDBridge driver detected: Digital Devices DVBCT V6.1 DVB adapter
[    4.645744] DDBridge: HW 00010007 REGMAP 00010003
[    4.645869] DDBridge: using 1 MSI interrupt(s)
[    4.647843] Port 0: Link 0, Link Port 0 (TAB 1): DUAL DVB-C/T
[    4.648847] Port 1: Link 0, Link Port 1 (TAB 2): NO MODULE
[    4.649846] Port 2: Link 0, Link Port 2 (TAB 3): NO MODULE
[    4.650247] DVB: registering new adapter (DDBridge)
[    4.650249] DVB: registering new adapter (DDBridge)
[    4.673271] stv0367dd: STV0367 DVB-C DVB-T demod with ChipID 60 found at adr 1F on i2c-7
[    4.973569] tda18212 7-0060: NXP TDA18212HN/M successfully identified
[    4.973585] ddbridge 0000:05:00.0: DVB: registering adapter 0 frontend 0 (STV0367 DVB-C DVB-T)...
[    4.974729] stv0367dd: STV0367 DVB-C DVB-T demod with ChipID 60 found at adr 1E on i2c-7
[    5.050153] stv0367dd: i2c_write error ([1e] f010: ff)
[    5.050284] stv0367dd: i2c_write error ([1e] f020: 2a)
[    5.050693] stv0367dd: i2c_write error ([1e] f021: d6)
[    5.050709] stv0367dd: i2c_write error ([1e] f022: 55)
[    5.050724] stv0367dd: i2c_write error ([1e] f023: 55)
[    5.050739] stv0367dd: i2c_write error ([1e] f09a: 14)
[    5.050754] stv0367dd: i2c_write error ([1e] f09b: ae)
[    5.050769] stv0367dd: i2c_write error ([1e] f09c: 56)
[    5.050784] stv0367dd: i2c_write error ([1e] f06b: 00)
[    5.050799] stv0367dd: i2c_write error ([1e] f272: 70)
[    5.050814] stv0367dd: i2c_write error ([1e] f273: c0)
[    5.050829] stv0367dd: i2c_write error ([1e] f274: 20)
[    5.050844] stv0367dd: i2c_write error ([1e] f280: 40)
[    5.050859] stv0367dd: i2c_write error ([1e] f272: 71)
[    5.050874] stv0367dd: i2c_write error ([1e] f272: 70)
[    5.050889] stv0367dd: i2c_write error ([1e] f002: 10)
[    5.050904] stv0367dd: i2c_write error ([1e] f016: 01)
[    5.050919] stv0367dd: i2c_write error ([1e] f017: 8a)
[    5.050933] stv0367dd: i2c_write error ([1e] f4b8: 85)
[    5.050948] stv0367dd: i2c_write error ([1e] f0c1: 0d)
[    5.050963] stv0367dd: i2c_write error ([1e] f0d8: 1b)
[    5.050978] stv0367dd: i2c_write error ([1e] f0d9: e8)
[    5.050993] stv0367dd: i2c_write error ([1e] f0da: 18)
[    5.051008] stv0367dd: i2c_write error ([1e] f0d7: 8b)
[    5.051023] stv0367dd: i2c_write error ([1e] f0db: 04)
[    5.051038] stv0367dd: i2c_write error ([1e] f465: 23)
[    5.051053] stv0367dd: i2c_write error ([1e] f45c: 01)
[    5.051068] stv0367dd: i2c_write error ([1e] f48e: 83)
[    5.051083] stv0367dd: i2c_write error ([1e] f43c: 05)
[    5.051098] stv0367dd: i2c_write error ([1e] f0c1: 00)
[    5.051113] stv0367dd: i2c_write error ([1e] f001: 58)
[    5.052680] stv0367dd: i2c_write error ([1e] f001: d8)
[    5.052719] stv0367dd: i2c_write error ([1e] f001: 58)
[    5.052739] tda18212: probe of 7-0063 failed with error -5
[    5.052747] ddbridge 0000:05:00.0: TDA18212 tuner not found. Device is not fully operational.
[    5.052750] stv0367dd: release()
[    5.052754] port_attach on port 0 failed

Hilft Dir das weiter?

Zitat von gentoo-vdr

Klar, hier das Kernellog:

Sieht doch gut aus!

Zitat von gentoo-vdr

VDR (Version 2.2.0) funktioniert und zeigt mir für das SNR einen vollen Balken an (vorher nur ein kleiner Strich), in femon steht bei STR, SNR, BER und UNC nun aber gar nichts mehr. STR zeigte zuvor immer 0%, SNR war zwar auch 0%, aber dort hatte ich immerhin Hex-Werte, die bei der Beurteilung der Signalqualität halfen.

Hmm, das ist jetzt doof: Fix in die VDR Sourcen geschaut, in dvbdevice.c wird nur versucht, über die "Legacy API" (DVBv3) die Signalstatistik auszulesen, das sollte aber eigentlich per APIv5 (DTV_PROPERTY_*) passieren... Den vollen Balken siehst Du, weil im Fehlerfall bzw. "not implemented" der SNR-Wert pauschal auf MAX (0xffff) gesetzt wird. Das müsste also in den VDR-Code implementiert werden. Ist für das ddbridge-Projekt jetzt dusselig, weil in 2013 in einem Kommentar im CXD2843-Patch (von Maik Broemme) darauf verwiesen wurde, doch bitte DVBv5 in get_frontend() zu implementieren.

Der Code in dvbdevice.c sieht jetzt auch nicht so fürchterlich kompliziert aus, das könnte recht fix (von einem VDR-Entwickler ) erweitert werden, bzw. sollte auch gemacht werden, da neuere DVB-Module tendenziell eher die neue API implementieren.

Zitat von gentoo-vdr

Leider hatte ich vorhin direkt nach dem Reboot wieder I2C-Fehler:

Code

[    4.974729] stv0367dd: STV0367 DVB-C DVB-T demod with ChipID 60 found at adr 1E on i2c-7
[    5.050153] stv0367dd: i2c_write error ([1e] f010: ff)
[...]

Hilft Dir das weiter?

Das hilft zumindest schonmal insofern weiter, dass die Probleme beim Slave-Demod auftreten (zweites Frontend auf Port 0 - adr 1e) und NACH dem Schreiben der drei Register-Inittabs die Probleme anfangen. Warum ist mir nicht wirklich klar, da prinzipiell einfach mit weiteren Register-Writes fortgefahren wird. Ist die Frage, ob das immer an dieser Stelle auftritt, wenn es auftritt. Ich erinner' mich auf jeden Fall, dass beim letzten Mal auf meinem Server zumindest die Menge der Fehler ähnlich war.

TL/DR: Ausser, dass ungefähr klar ist, wo und wann es Probleme gibt, hab' ich dazu spontan keine Idee, zumal nur Register mit Inhalt gefüttert werden.

EDIT: Habe dazu mal rjkm kontaktiert, bitte lass' Dein Kernel-Log im Post mal so stehen.
EDIT2: Die i2c_write errors fangen hier an.

Zitat von nst

TL/DR: Ausser, dass ungefähr klar ist, wo und wann es Probleme gibt, hab' ich dazu spontan keine Idee, zumal nur Register mit Inhalt gefüttert werden.

Ich habe jetzt mal den Init Code vom TDA18212DD aus dddvb in drivers/media/tuners/tda18212.c eingestrickt (TDA18212 ist das Stück Tuner, das an den STV0367 Demod angeklemmt ist). In dddvb passiert hier wesentlich mehr (bzw. überhaupt was, anstatt nur "identifizieren und fertig"), z.B. wird irgendwas gegeneinander kalibriert, und in Bezug auf die Master/Slave-Konstellation wird einiges gemacht (was die ganzen Register-Pokes machen, kann ich nur erraten, aber das "drumherum" lässt einiges erahnen). Möglicherweise sind dies Dinge, die - wenn sie fehlen - Einfluss auf die Stabilität des Demods nehmen und das Ding abstürzen lassen können.

Zu finden wie immer im mediatree/master-ddbridge-testing-Branch, konkret in Commits 2eed47d und 7372e6b. Funktional derzeit kein Unterschied feststellbar.

Nebenbei, wenn der Port nach i2c_write errors leer ist, liefert der erste Test schon nichts mehr zurück, möglicherweise weil der I2C-Bus resettet werden möchte. Das muss aber Digital Devices beantworten, ob das möglich ist.

EDIT: Neue Commit-IDs, standby-Logspam auf Level Debug reduziert.

Schöne Feiertage,
nst

Zitat von nst

Ich habe jetzt mal den Init Code vom TDA18212DD aus dddvb in drivers/media/tuners/tda18212.c eingestrickt (TDA18212 ist das Stück Tuner, das an den STV0367 Demod angeklemmt ist). In dddvb passiert hier wesentlich mehr (bzw. überhaupt was, anstatt nur "identifizieren und fertig"), z.B. wird irgendwas gegeneinander kalibriert, und in Bezug auf die Master/Slave-Konstellation wird einiges gemacht (was die ganzen Register-Pokes machen, kann ich nur erraten, aber das "drumherum" lässt einiges erahnen). Möglicherweise sind dies Dinge, die - wenn sie fehlen - Einfluss auf die Stabilität des Demods nehmen und das Ding abstürzen lassen können.

Danke! Ich werde testen, ob damit immer noch I2C-Fehler auftreten. Bis jetzt sieht es gut aus. Ich werde berichten, wie die Langzeiterfahrungen sind.

Ich wünsche ebenfalls schöne Feiertage!

Hi. Was muß ich denn tun um diese Treiber bei mir zu testen?

Ich habe ne cine mit duoflex s2
Mit den dddvb-dkms treibern gehen Tuner 3und4mal und mal nicht. Daher bin ich auf der Suche nach was stabilen

Zitat von masterpete

Hi. Was muß ich denn tun um diese Treiber bei mir zu testen?

Siehe https://github.com/herrnst/ddd…ile-using-media_build.git

Zitat von masterpete

Ich habe ne cine mit duoflex s2
Mit den dddvb-dkms treibern gehen Tuner 3und4mal und mal nicht. Daher bin ich auf der Suche nach was stabilen

Feedback in Form von der Ausgabe von dmesg und lsmod auf z.B. pastebin wäre auch hier hilfreich (immer noch auf der Suche nach Feedback mit einer CineS2 v7 bzw. einer Karte mit STV0910+STV6111+LNBH25 - Bridge oder Flexmodul).

Ok, die Erweiterungen im TDA18212 scheinen NICHT beim i2c_write Problem geholfen zu haben.

Mir ist gerade nach vier Tagen Laufzeit das ddbridge-Modul mit den anscheinend bekannten MSI-I2C-Problemen ausgeflippt (Pünktlich um 23:05 Uhr wacht das Backup am Server auf, und zeitgleich ist am Client das TV-Bild eingefroren). Es hat in der Vergangenheit auch schon jemand gepostet, dass es in Verbindung mit "übereifrigen SATA-Controllern" wohl Probleme geben kann - passt ja quasi. Im Kernel-Log hat sich das Ganze auszugsweise so bemerkbar gemacht.

Nach anschliessendem "rmmod ddbridge" (hat ein Weilchen gedauert, war aber am Ende erfolgreich) und "modprobe ddbridge" dann nach längerer Zeit mal wieder das "dma_generic_alloc_coherent() page allocation failure" Problem (Kernel-Log). Ich hatte also schon einen Reboot der Kiste eingeplant, eine Minute später hat der Kernel aber anscheinend seine Resourcen umsortiert, und das Modul konnte geladen werden. Allerdings jetzt mit i2c_write-Fehler im STV0367. Interessant dabei, dass der Fehlerzustand diesmal bereits beim primären (Master) Demod aufgetreten ist (Kernel-Log).

Daher habe ich jetzt kurzerhand im mediatree/master-ddbridge-testing-Branch einen Delay in write_init_table() eingepflanzt, der das Register-Poking alle 100 Writes für 100ms drosselt. Evtl. hilft das zumindest als Workaround. Und nebenbei läuft ddbridge jetzt mit "msi=0", und ich tendiere dazu, das in ddbridge.c als Default zu setzen.

EDIT: Commit-ID / Rebase

Neu in mediatree/master-ddbridge-testing: ddbridge Kernel-Option zum Switchen des MSI-Defaults

Damit lässt sich der Default von "option msi=<X>" auf "aus" setzen. Kommt nur zur Anwendung, wenn im Kernel CONFIG_PCI_MSI aktiv ist. MSI-Support kann zum Testen nach wie vor per "option msi=1" aktiviert werden. Könnte für User interessant sein, die mit aktivem MSI-Support in Probleme laufen.

@gentoo-vdr, gibts bei Dir neue Erkenntnisse bzgl. i2c_write Problemen, auch mit aktuellem testing-Tree inkl. write_init_table() tryfix/workaround? Mein Server und die DD-Karte läuft jetzt mit msi=0 seit einer Woche wie gewohnt störungsfrei.

Zitat von nst

Feedback in Form von der Ausgabe von dmesg und lsmod auf z.B. pastebin wäre auch hier hilfreich (immer noch auf der Suche nach Feedback mit einer CineS2 v7 bzw. einer Karte mit STV0910+STV6111+LNBH25 - Bridge oder Flexmodul).

habe dir eine PM geschickt.
hast du eine Idee?

Zitat von gentoo-vdr

Siehe https://github.com/herrnst/ddd…ile-using-media_build.git

ich bin nicht so tief im linux aber bis zum checkout komm ich.
Ich wollte ja testing mal machen.
nun kommt der fehler

root@w:/usr/src/dvbdev/dddvb-linux-kernel# git checkout mediatree/master-ddbridge-testing
Bereits auf 'mediatree/master-ddbridge-testing'
Ihr Branch ist auf dem selben Stand wie 'origin/mediatree/master-ddbridge-testing'.

Zitat von masterpete

habe dir eine PM geschickt.
hast du eine Idee?

An Port 1 (TAB 2) sehe ich ein STV0910/STV6111/LNBH25-basiertes Flexmodul. Aus welcher Quelle hast Du die Treiber gerade am laufen?

Zitat von nst

An Port 1 (TAB 2) sehe ich ein STV0910/STV6111/LNBH25-basiertes Flexmodul. Aus welcher Quelle hast Du die Treiber gerade am laufen?

Ja ich bin mir nicht 100% sicher.
Entweder aus dem easyvdr dkms ppa
oder
http://support.digital-devices…ledgebase.php?article=151
bekomm ich das irgendwie sicher raus?

Zitat von masterpete

Code

root@w:/usr/src/dvbdev/dddvb-linux-kernel# git checkout mediatree/master-ddbridge-testing
Bereits auf 'mediatree/master-ddbridge-testing'
Ihr Branch ist auf dem selben Stand wie 'origin/mediatree/master-ddbridge-testing'.

Das ist kein Fehler, nur ein Hinweis - alles gut

Zitat von masterpete

bekomm ich das irgendwie sicher raus?

Nein, das müsste in der Kernellog-Ausgabe stehen bzw. in den Modulen markiert sein. Wenn Du per media_build aus meinem Kerneltree kompilierst, taucht zusätzlich eine "Warnung, Du benutzt experimentelle Module"-Meldung aus dem "media"-Modul, die würden sich daher (zumindest ansatzweise) identifizieren lassen.

Wichtiger Rat: Mach' ein Backup von /lib/modules/<laufender-kernel> bevor Du mit "make install" drivers/media/ ersetzt, die Verwendung des in-tree-LNBH25-Treibers ist komplett ungetestet und kann Nicht-Funktionieren des Flex-Moduls zur Folge haben - da hilft ein Backup zum schnellen Wiederherstellen von Dateien und Funktion ungemein

Ich werde nun clonezilla anwerfen. Wie mach ich nach dem NICHT Fehler oben weiter? Wie installiere ich den testing?

Was ist das Kernel log? Wo finde ich das?

Gesendet von meinem Huawei Honor 7

Zitat von masterpete

Ich werde nun clonezilla anwerfen. Wie mach ich nach dem NICHT Fehler oben weiter? Wie installiere ich den testing?

Einfach nach "git checkout mediatree/master-ddbridge-testing" weiter der Anleitung folgen.

Zitat von masterpete

Was ist das Kernel log? Wo finde ich das?

Ausgabe von "dmesg" = Kernel Log.

root@w:/usr/src/dvbdev/media_build# modprobe ddbridge
modprobe: ERROR: could not insert 'ddbridge': Invalid argument

[  791.716037] media: Linux media interface: v0.10
[  791.716263] ddbridge: disagrees about version of symbol dvb_dmxdev_init
[  791.716267] ddbridge: Unknown symbol dvb_dmxdev_init (err -22)
[  791.716289] ddbridge: disagrees about version of symbol dvb_ca_en50221_init
[  791.716291] ddbridge: Unknown symbol dvb_ca_en50221_init (err -22)
[  791.716328] ddbridge: disagrees about version of symbol dvb_register_adapter
[  791.716330] ddbridge: Unknown symbol dvb_register_adapter (err -22)
[  791.716343] ddbridge: disagrees about version of symbol dvb_generic_open
[  791.716345] ddbridge: Unknown symbol dvb_generic_open (err -22)
[  791.716358] ddbridge: disagrees about version of symbol dvb_dmx_swfilter_packets
[  791.716360] ddbridge: Unknown symbol dvb_dmx_swfilter_packets (err -22)
[  791.716384] ddbridge: disagrees about version of symbol dvb_dmx_release
[  791.716386] ddbridge: Unknown symbol dvb_dmx_release (err -22)
[  791.716400] ddbridge: disagrees about version of symbol dvb_unregister_device
[  791.716402] ddbridge: Unknown symbol dvb_unregister_device (err -22)
[  791.716418] ddbridge: disagrees about version of symbol dvb_ca_en50221_release
[  791.716420] ddbridge: Unknown symbol dvb_ca_en50221_release (err -22)
[  791.716433] ddbridge: disagrees about version of symbol dvb_generic_release
[  791.716435] ddbridge: Unknown symbol dvb_generic_release (err -22)
[  791.716446] ddbridge: disagrees about version of symbol dvb_net_init
[  791.716448] ddbridge: Unknown symbol dvb_net_init (err -22)
[  791.716465] ddbridge: disagrees about version of symbol dvb_dmxdev_release
[  791.716467] ddbridge: Unknown symbol dvb_dmxdev_release (err -22)
[  791.716485] ddbridge: disagrees about version of symbol dvb_frontend_detach
[  791.716487] ddbridge: Unknown symbol dvb_frontend_detach (err -22)
[  791.716500] ddbridge: disagrees about version of symbol dvb_net_release
[  791.716501] ddbridge: Unknown symbol dvb_net_release (err -22)
[  791.716519] ddbridge: disagrees about version of symbol dvb_unregister_frontend
[  791.716521] ddbridge: Unknown symbol dvb_unregister_frontend (err -22)
[  791.716535] ddbridge: disagrees about version of symbol dvb_register_device
[  791.716537] ddbridge: Unknown symbol dvb_register_device (err -22)
[  791.716550] ddbridge: disagrees about version of symbol dvb_register_frontend
[  791.716552] ddbridge: Unknown symbol dvb_register_frontend (err -22)
[  791.716563] ddbridge: disagrees about version of symbol dvb_unregister_adapter
[  791.716565] ddbridge: Unknown symbol dvb_unregister_adapter (err -22)
[  791.716575] ddbridge: disagrees about version of symbol dvb_dmx_init
[  791.716576] ddbridge: Unknown symbol dvb_dmx_init (err -22)
[  791.716593] ddbridge: disagrees about version of symbol cxd2099_attach
[  791.716594] ddbridge: Unknown symbol cxd2099_attach (err -22)

nach einem reboot - erstmal bild. was brauchst du jetzt?

aber gleiches problem wie vorher
neustart nur 2 tuner
nach vdr und desktop neustart alle Tuner verfügbar.
EDIT: jetzt nur noch 2 tuner verlässlich

Wird ggf für die zusätzlichen Tune noch ne andere Treiber version genommen?
http://pastebin.com/DSbXSiqJ
http://pastebin.com/rT9SYG6d

Zitat von nst

@gentoo-vdr, gibts bei Dir neue Erkenntnisse bzgl. i2c_write Problemen, auch mit aktuellem testing-Tree inkl. write_init_table() tryfix/workaround? Mein Server und die DD-Karte läuft jetzt mit msi=0 seit einer Woche wie gewohnt störungsfrei.

Ich habe auch keine I2C-Fehler mehr gehabt (seit nun fast zwei Wochen). Die zusätzliche Initialisierung scheint etwas gebracht zu haben. Mein Treiber ist übrigens noch auf dem Stand von Commit 48df2f7173c693f3590071bc1108558b51131605. Die Wartezeit, die Du danach noch implementiert hast, scheint bei mir (bis jetzt) nicht erforderlich zu sein.
Soll ich auch noch mal mit msi=0 testen? Ich hatte mit aktiviertem MSI bisher nie Probleme. Was sind denn eigentlich die Vor- und Nachteile von msi=0 bzw. msi=1?