Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

UFO · March 21, 2014 at 10:18 PM

Hi,

Please include the mutex patch

Diff

--- media-build-experimental-dkms-0~20140312.204530.orig/media-build-experimental-0~20140312.204530/linux/drivers/media/dvb-core/dvbdev.c	2014-03-21 10:04:22.306392000 +0100
+++ media-build-experimental-dkms-0~20140312.204530/media-build-experimental-0~20140312.204530/linux/drivers/media/dvb-core/dvbdev.c	2014-03-21 10:08:39.942392000 +0100
@@ -82,7 +82,11 @@
 		file->private_data = dvbdev;
 		replace_fops(file, new_fops);
 		if (file->f_op->open)
+    	{
+        	mutex_unlock(&dvbdev_mutex);
 			err = file->f_op->open(inode,file);
+        	mutex_lock(&dvbdev_mutex);
+    	}
 		up_read(&minor_rwsem);
 		//mutex_unlock(&dvbdev_mutex);
 		return err;

Display More

This patch removes mutex protection from the 'open' call. Looks strange to me.

If the patch is correct, you can probably remove the mutex_lock/mutex_unlock calls completely from the routine.
Otherwise the patch is wrong, and you cannot be sure that the 'new_fops' are still in effect when 'open' is called.

I am not aware of any problems with this piece of code. So unless someone provides a good explanation, I will not apply this patch. Sorry.

CU
Oliver

gda · March 22, 2014 at 12:08 AM

Quote from Wild Penguin

jeee: I've tried your patch, unfortunately it has no effect on my issue. But thanks anyway!

Wild Penguin, jeees post is unrelated to your problem. Misunderstandings like this happens if you hijack a thread instead creating a new one.

Gerald

musv · March 22, 2014 at 7:33 AM

Hatte auch den Fehler:

Code

modprobe ddbridge


ddbridge: Unknown symbol dvb_usercopy (err 0)

Quote from UFO

"make menuconfig" trägt - außer bei diesem einen Modul - überall 'y' ein. Richtig wäre natürlich 'm'. Wir bauen Module.

Muß ich mir anschauen. Der Bug kommt jedenfalls von media_build upstream.

CU
Oliver

Ok, das war jetzt der Hinweis, der mir die Lösung brachte.

Hab normalerweise alles fest reincompiliert, was geht. Bei meiner älteren Version (Kernel 3.9.3) funktionierte das auch noch mit dvb-core (media_support=y).

Dann hab ich jetzt ewig in der Kernelconfig gesucht, wo ich das im Untermenü "Multimedia Support" umstellen kann. Ging nicht. Im Untermenü konnte ich kein Sternchen durch ein 'm' ersetzen. Die Lösung war dann, den gesamten "Multimedia Support" bei "Device Drivers" als Modul zu bauen. Damit baut es auch die ganzen rc_maps für Input Lirc als Modul. Ist nicht schön. Aber funktioniert erst mal soweit (Gentoo: Kernel 3.13.6). Zumindest läuft vdr wieder.

Wild Penguin · March 23, 2014 at 8:52 AM

Quote from gda

Wild Penguin, jeees post is unrelated to your problem. Misunderstandings like this happens if you hijack a thread instead creating a new one.

Gerald,

Youre right; my apologies for adding noise!

I'm not sure why I didn't start a new thread in the first place... however, I did get some help here, and in case I have something to add, I will start a new thread for the issue I'm having.

ManOki · March 24, 2014 at 4:05 PM

hi guys,

i've tried to install the current driver according to the installation guide in the first post in the topic (or alternativ in the wiki: http://www.linuxtv.org/wiki/index.php/Digital_Devices_DuoFlex_C&T ).
On the second step the installation fails cause there is a 404 downloading the driver package.

Code

#make download
make -C linux/ download
make[1]: Entering directory `/root/media_build_experimental/linux'
wget http://linuxtv.org/downloads/drivers/linux-media-2014-03-06.tar.bz2.md5 -O linux-media.tar.bz2.md5.tmp
--2014-03-24 16:00:40-- http://linuxtv.org/downloads/drivers/linux-media-2014-03-06.tar.bz2.md5
Auflösen des Hostnamen »linuxtv.org (linuxtv.org)«... 130.149.80.248
Verbindungsaufbau zu linuxtv.org (linuxtv.org)|130.149.80.248|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 404 Not Found
2014-03-24 16:00:40 FEHLER 404: Not Found.


make[1]: *** [download] Fehler 8
make[1]: Leaving directory `/root/media_build_experimental/linux'
make: *** [download] Fehler 2

Display More

do i need to change something? am i using the correct repository? is there a temporary problem?

thanks for help
manoki

PS: hope this is the correct thread.

UFO · March 24, 2014 at 5:10 PM

The driver package was moved. Fixed.

CU
Oliver

UFO · March 27, 2014 at 6:08 PM

Treiber unterstützt nun auch die cineCT v7, ddbridge auf Version 0.9.13 aktualisiert.

CU
Oliver

fnu · March 27, 2014 at 6:11 PM

UFO

Super Sache, danke für Deine Mühen ...

Gruß
Frank

heinbloed · March 27, 2014 at 7:01 PM

von mir auch ein großes DANKE für Deine Arbeit !
Aber auch gleich zur Sicherheit eine Frage hinterher:
Support für beide Modelle (Cine CT2 V7 und Cine C2T2 V7 ) ?

UFO · March 28, 2014 at 12:33 AM

Habe die ID der cine C2T2 v7 eingetragen, sollte nun auch funktionieren.

CU
Oliver

cyjoe · March 29, 2014 at 11:12 AM

Hallo,

bei mir läuft eine Octopus in einer virtuellen Maschine (kvm) mit intel vt-d, Host-Kernel 3.2.0-4-amd64 Debian wheezy, Gastsystem Ubuntu 1204 LTS 3.2.0-60 i686. Der VDR ist yavdr-unstable.

Eigentlich lief die Karte seit 2012 stabil mit den media-build-experimental-Modulen.

In KW13 habe ich aber yavdr upgedatet und auch das Treiberrepository. Seit dem läuft die Karte nicht mehr rund.

Der Empfang funktioniert zunächst einwandfrei ohne Ruckler o.Ä. Nach einigen Minuten kommt dann auf dem Gastsystem die Kernelfehlermeldung:

Mar 28 17:56:59 vdr kernel: [ 626.112147] DDBridge I2C timeout, card 0, port 0
Mar 28 17:56:59 vdr kernel: [ 626.112343] drxk: i2c write error at addr 0x2a
Mar 28 17:56:59 vdr kernel: [ 626.112525] drxk: Error -5 on SetQAM64
Mar 28 17:56:59 vdr kernel: [ 626.112677] drxk: Error -5 on SetQAM
Mar 28 17:56:59 vdr kernel: [ 626.112822] drxk: Error -5 on Start
Mar 28 17:56:59 vdr kernel: [ 626.556538] drxk: SCU not ready
Mar 28 17:56:59 vdr kernel: [ 626.556681] drxk: GetQAMLockStatus status = fffff

Die Fehlermeldungen
Mar 28 17:57:00 vdr kernel: [ 627.788884] drxk: Error -5 on GetLockStatus
Mar 28 17:57:01 vdr kernel: [ 628.096606] drxk: SCU not ready
Mar 28 17:57:01 vdr kernel: [ 628.096737] drxk: GetQAMLockStatus status = fffffffb

wiederholen sich fortan sehr kurzen Intervallen und spammen das log zu.

Irgendwann stürzt dann auch der Treiber ab.

Hat sich irgend etwas verändert? Ist der Treiber zickiger geworden, was die interrupts angeht?

UFO · March 29, 2014 at 12:55 PM

Quote from cyjoe

bei mir läuft eine Octopus in einer virtuellen Maschine (kvm) mit intel vt-d, Host-Kernel 3.2.0-4-amd64 Debian wheezy, Gastsystem Ubuntu 1204 LTS 3.2.0-60 i686. Der VDR ist yavdr-unstable.

Eigentlich lief die Karte seit 2012 stabil mit den media-build-experimental-Modulen.

In KW13 habe ich aber yavdr upgedatet und auch das Treiberrepository. Seit dem läuft die Karte nicht mehr rund.

Der Empfang funktioniert zunächst einwandfrei ohne Ruckler o.Ä. Nach einigen Minuten kommt dann auf dem Gastsystem die Kernelfehlermeldung:

Mar 28 17:56:59 vdr kernel: [ 626.112147] DDBridge I2C timeout, card 0, port 0
Mar 28 17:56:59 vdr kernel: [ 626.112343] drxk: i2c write error at addr 0x2a
...
Irgendwann stürzt dann auch der Treiber ab.

Hat sich irgend etwas verändert? Ist der Treiber zickiger geworden, was die interrupts angeht?

Display More

Ein Log sowohl vom funktionierenden als auch nicht funktionierenden Treiberstand wäre hilfreich. Nur so kann man erkennen, welche Version funktioniert und welche nicht...

Ab einer bestimmten Treiberversion ist MSI per Default deaktiviert.

Um zu prüfen, ob es daran liegt, in ddbridge.c Zeile 28

Code

#undef CONFIG_PCI_MSI

auskommentieren oder löschen. Funktioniert es damit wieder?

CU
Oliver

cyjoe · March 29, 2014 at 1:23 PM

Ich hatte ein ähntliches Problem vor längerer Zeit schon einmal:

http://www.linux-kvm.com/content/pci-pa…devices-cine-s2

Zwischenzeitlich habe ich die Hardware gewechselt, Danach funktionierte es.

Ich habe nun wie in Thread (viel später) empfohlen im Gastsystem die Kerneloption pcie_pme=nomsi übergeben.

Jetzt läuft das System seit gut 2 h stabil.

Offensichtlich hat es also etwas mit MSI zu tun, jedoch erscheint es mir jetzt widersprüchlich, dass es anscheinend hilft, im Kernel MSI deaktivieren, obwohl die neuere Treiberversion MSI ohnehin nicht nutzt.

Wenn Interesse besteht (und ich die Zeit finde), versuche ich eine paar Kombinationen einmal aus.

Die letzte funktionierende Treiberversion weiß ich leider nicht. Es könnte Ende 2013 gewesen sein.

Edit:
Kernellog vom Original 3.2.0 Media-Stack: http://pastebin.com/nHwWtYFR mit I2C-timeout
Kernellog vom zuletzt noch funktionierenden experimental Media-Stack: http://pastebin.com/4WST3mEs
kein I2C-timeout

Kernellog von aktueller Revision, mit I2C-timeout: http://pastebin.com/LE7CqaMw
Kernellog von aktueller Revision, mit Kerneloption pcie_pme=nomis, seit mehr als 2 h stabil: http://pastebin.com/xDbZ2Zt4

UFO · March 29, 2014 at 3:19 PM

Quote from cyjoe

Ich hatte ein ähntliches Problem vor längerer Zeit schon einmal:

http://www.linux-kvm.com/content/pci-pa…devices-cine-s2

Zwischenzeitlich habe ich die Hardware gewechselt, Danach funktionierte es.

Ich habe nun wie in Thread (viel später) empfohlen im Gastsystem die Kerneloption pcie_pme=nomsi übergeben.

Jetzt läuft das System seit gut 2 h stabil.

Offensichtlich hat es also etwas mit MSI zu tun, jedoch erscheint es mir jetzt widersprüchlich, dass es anscheinend hilft, im Kernel MSI deaktivieren, obwohl die neuere Treiberversion MSI ohnehin nicht nutzt.

Display More

Richtig, damit wird MSI generell deaktiviert. Abwarten, ob dies tatsächlich hilft.

Unterschiedliche Chipsätze - dazu noch Virtualisierung - ergeben ein ziemliches Schlamassel.
Erinnert mich an die Anfangszeiten von PCI, wo es auch haufenweise Probleme gab.

Quote

...
Kernellog vom Original 3.2.0 Media-Stack: http://pastebin.com/nHwWtYFR mit I2C-timeout

Dazu gibt es keinen Support meinerseits.

Quote

Kernellog vom zuletzt noch funktionierenden experimental Media-Stack: http://pastebin.com/4WST3mEs
kein I2C-timeout

Treiberstand vom 15.4.2013, ddbridge Version 0.8, MSI in ddbridge aktiv:

Code

DDBridge 0000:00:07.0: irq 43 for MSI/MSI-X

Quote

Kernellog von aktueller Revision, mit I2C-timeout: http://pastebin.com/LE7CqaMw

Treiberstand vom 24.3.2014, ddbridge Version 0.9.12, MSI in ddbridge deaktiviert, ansonsten aktiviert.

Quote

Kernellog von aktueller Revision, mit Kerneloption pcie_pme=nomis, seit mehr als 2 h stabil: http://pastebin.com/xDbZ2Zt4

ditto

Im Log kann ich keinen Unterschied erkennen. Insbesondere auch nicht, was MSI betrifft. Ist jene Kerneloption wirklich aktiv?

CU
Oliver

cyjoe · March 31, 2014 at 9:45 PM

Nach zwei Tagen stabilem Betrieb kam der Fehler erneut, spammte das Log zu und brachte den Treiber zum Absturz. Modul neu geladen -> geht wieder.

Nun probiere ich es mal ohne die Option pcie_pme=nomsi und mit #define CONFIG_PCI_MSI in ddbridge.c

dmesg:
[ 3.185150] ddbridge 0000:00:07.0: irq 43 for MSI/MSI-X

cyjoe · April 3, 2014 at 7:00 PM

Seit nunmehr fast 72 Stunden läuft das System stabil im Dauerbetrieb.

Warum wurde MSI für ddbridge deaktiviert?

UFO · April 5, 2014 at 12:11 AM

Quote from cyjoe

Warum wurde MSI für ddbridge deaktiviert?

Vermutlich gab es irgendwelche Probleme. In Treiber 0.9.5 war es noch aktiviert.

Ich hatte nie Probleme, weder "mit" noch noch "ohne".

CU
Oliver

cyjoe · April 5, 2014 at 12:42 PM

Nun, wie dem auch sei, scheinen durch MSI meine Stabilitätsprobleme verschwunden zu sein. Vielen Dank für die Unterstützung.

jasminj · April 5, 2014 at 12:53 PM

Quote from UFO

Vermutlich gab es irgendwelche Probleme. In Treiber 0.9.5 war es noch aktiviert.

Man könnte Ralph fragen, warum das gemacht wurde. Anscheinend ist es für manche Mainboards notwendig. Ev. könnte man eine Treiber Option daraus machen, damit man es auch ohne zu compilieren wieder aktivieren kann.

LG
Jasmin

jasminj · April 11, 2014 at 2:10 AM

Quote from jasminj

Man könnte Ralph fragen, warum das gemacht wurde

Seine Antwort:

Quote

Da wir bisher eher von Problemen mit MSI gehört hatten, hatte ich es als Default ausgeschaltet. Nun läuft
es also wohl eher darauf hinaus, daß es von der Hardware und/oder auch der Anwendung einer Virtualisierung
abhängt. Ich werde es wohl dann in einen Modul-Parameter ändern.

LG
Jasmin

Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

Participate now!

Tags