Update: Optimierter av7110 Treiber

Hallo,

...nur mal so als Frage in die 'Runde'...

Wie ist denn der aktuelle Stand mit diesem Patch. Macht es Sinn diesen im Moment auf den aktuellen HG-Treiber anzuwenden bzw. ist er bereits darin enthalten? Oder noch besser gefragt, bringt er positive Änderungen für meinen 'production-VDR' oder gibt es damit Probleme?

Fragen über Fragen... Es wäre prima, wenn mir diese jemand beantworten könnte.

Danke, Gruss Steve135

Hi, würd mich auch interessieren ob der Patch schon irgendwo eingepflegt ist. Gruß Oga

Hmm schade geht im aktuellen tip nicht ( falls ich kinen Mist gebaut hab )
1 out of 5 hunks FAILED -- saving rejects to file linux/drivers/media/dvb/ttpci/av7110_hw.h.rej

War wohl nur ein type change (char -> u8 )
hat einwandfrei compiliert und laeuft auch soweit ich das sehen kann ( sind noch 3 Nova SE2 in meinem Headless )
Leider krieg ich das CAM nicht mehr.

Any ideas ?

Gruß

Fabian

Hallo Oliver,

bei dem Versuch den aktuellen av7110-refactoring treiber mit dem 2.6.23.1 Kernel via "make kernel-links" zu compilieren (gcc 4.2.1) gibt es folgendes Problem:

include/linux/compat.h:425:5: warning: "LINUX_VERSION_CODE" is not defined
include/linux/compat.h:425:26: warning: "KERNEL_VERSION" is not defined
include/linux/compat.h:425:40: error: missing binary operator before token "("
m

Einzeln ("make") läßt er sich übersetzen. Mache ich etwas grundsätzliches falsch oder gibt es da ein Problem?

Danke!

Martin

P.S.
Hat sich erledigt, wer lesen kann ist klar im Vorteil....
makelinks.sh <-> make kernel-links oder?

Es gehört nur am Rande zum Thema, aber da hier am intensivsten über die Treiberentwicklung debattiert wird: Wäre es auf Treiberebene denkbar, in das Interruptrouting einzugreifen, oder ist an der Stelle schon alles zu spät und man kann nur noch den verwenden, den das System vergeben hat? Bzw. könnte man den vor dem Laden des Moduls noch irgendwie ändern?

Ich frage, weil der nvidia-Grafikkartentreiber auf Dualcoresystemen ein Problem mit shared interrupts zu haben scheint, welches auf neueren Kernelversionen inzwischen nervig oft vorkommt und das Mainboard standardmaessig nvidia und PCI1 auf Interrupt 16 sowie PCI2 auf Interrupt 17 zuweist. Trotz intensiver Benutzung von Tante Google habe ich auch noch nicht herausgefunden, ob es eine Kerneloption o.ae. gibt, mit der ich das beeinflussen kann.

Es wäre schon eine mächtige Kerneloption, die in der Lage ist, eine Kupferverbindung auf dem Mainboard umzuverdrahten. Üblicherwerise ist die INTA-Leitung des ersten PCI-Slot direkt verbunden mit dem IRQ des AGP/PCIEx16-Slot. Da hilft nur das leer lassen des ersten PCI-Slots, was ja auch der Kühlung der Grafikkarte gut tut.

Gruß,

Udo

Zitat

Original von Urig
Es wäre schon eine mächtige Kerneloption, die in der Lage ist, eine Kupferverbindung auf dem Mainboard umzuverdrahten. Üblicherwerise ist die INTA-Leitung des ersten PCI-Slot direkt verbunden mit dem IRQ des AGP/PCIEx16-Slot. Da hilft nur das leer lassen des ersten PCI-Slots, was ja auch der Kühlung der Grafikkarte gut tut.

PCIe benutze ich gar nicht, nur die Onboard-Grafik. Haette daher gehofft, dass das APIC da noch was machen kann. Leer lassen ist leider keine Option, es sind eh schon nur zwei (und in beiden stecken DVB-Karten). Wenn ich Dich recht verstehe, brauche ich also auch gar nicht weiter darüber nachdenken, ob eine separate Grafikkarte das Problem beheben würde? (War eh nur als Notlösung angedacht, weil mir der Energieverbrauch der Büchse eigentlich jetzt schon zu hoch ist...)

Hallo,

wollte mal wieder ein update machen, leider passt irgend etwas im HG von Oliver von nicht mehr (zu mein system).

Building modules, stage 2.
  MODPOST
WARNING: "videobuf_to_dma" [/mnt/data/suse10-src/v4l-dvb-20071203-perf2/v4l/saa7146_vv.ko] undefined!
WARNING: "videobuf_queue_pci_init" [/mnt/data/suse10-src/v4l-dvb-20071203-perf2/v4l/saa7146_vv.ko] undefined!

Per HG geladen von : http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring

aus dem normalen HG sieht es nicht besser aus :

Building modules, stage 2.
  MODPOST
WARNING: "videobuf_to_dma" [/mnt/data/suse10-src/v4l-dvb-20071203/v4l/saa7146_vv.ko] undefined!
WARNING: "videobuf_queue_pci_init" [/mnt/data/suse10-src/v4l-dvb-20071203/v4l/saa7146_vv.ko] undefined!
WARNING: "videobuf_stop" [/mnt/data/suse10-src/v4l-dvb-20071203/v4l/saa7146_vv.ko] undefined!

Gruß
Viking

Zitat

Originally posted by UFO
Iirc hat sich beim videobuf-Zeug so einiges geändert.

Hast Du mal einen neuen, sauberen Checkout gemacht?
("make distclean" tut's vermutlich auch.)

Ja, der checkout von oben ist ein clean checkout.

Zitat

Falls da noch alte Module rumliegen, paßt es nicht mehr zusammen. (Ähnliche Probleme hat man, wenn man die entsprechenden Module des Kernels verwendet oder in den Kernel einkompiliert hat.)

Im kernel sind die DVB treiber einkompiliert, kann das der grund sein ?
Zum laden der module benutze ich rmmod.pl, der lädt die module mit ./xxx.ko das sollte also passen.

Oder liegt es evt. an dem Suse-kernel den ich benutze ? (hoffentlich nicht, würde gerne weiterhin den original kernel nutzen - habe ihn schon mit preemptive+100hz neu kompiliert)

Gruß
Viking

Zitat

Wenn man aufpaßt und sicherstellt, daß nicht versehentlich Module des Kernels geladen werden können, kann man die v4l/dvb-Kernel-Treiber evtl. auch als Module kompilieren.

Ich habe v4l/dvb Support im Kernel als Modul eingestellt.
Bin ich auf der sicheren Seite, wenn ich /lib/modules/2.6.xx/kernel/drivers/media lösche bevor ich 'make install' im Verzeichnis der dvb-sourcen aufrufe?

Zitat

Originally posted by skiller2k1
irgendwie komm ich grad beim Kernelbauen nicht weiter. Habe den 2.6.20.4 gezogen und per makelinks.sh die refactoring-Treiber eingelinkt.

Da ich vor dem gleichen Problem stand - wie cross-compile ich die Treiber passend für ein ganz anderes System - habe ich mir einen Weg gesucht, wie ich auch ohne makelinks ein Kernel-Paket mit aktuellen Modulen bekomme. Die ganz knappe Anleitung für Debian und Derivate:

1. Kernel ganz normal backen: (siehe diverse Anleitungen)
make-kpkg --rootcmd fakeroot --append-to-version -kernelname (...) kernel_image

2. Aktuelle Quellen aus hg mit gleichen Kernelquellen übersetzen:
make all SRCDIR=/usr/src/linux-x.x.x.x DESTDIR=/tmp/deb/ KERNELRELEASE=x.x.x.x-kernelname

3. Kernelpackage entpacken:
fakeroot dpkg -x /usr/src/linux-image-x.x.x.x-kernelname_1_i386.deb /tmp/deb
fakeroot dpkg -e /usr/src/linux-image-x.x.x.x-kernelname_1_i386.deb /tmp/deb/DEBIAN

4. hg-Treiber integrieren:
fakeroot make install SRCDIR=/usr/src/linux-x.x.x.x DESTDIR=/tmp/deb/ KERNELRELEASE=x.x.x.x-kernelname

5. Kernelpackage wieder zusammen packen:
fakeroot dpkg -b /tmp/deb /tmp/linux-image-x.x.x.x-kernelname_1_i386.deb

Und schon hat man ein Kernelpackage mit aktuellen Modulen, das man sauber auf dem Zielsystem installieren, und auch rückstandslos deinstallieren kann.

Gruß,

Udo

... und nochmal ich. Ein Problem habe ich trotzdem noch: Mit aktuellem 2.6.23.12 und dem aktuellen refactoring-Treiber Stand 31.10.2007 lassen sich drei Module nicht laden:

WARNING: Error inserting v4l1_compat (/lib/modules/2.6.23.12/kernel/drivers/media/video/v4l1-compat.ko): Invalid module format
WARNING: Error inserting v4l2_common (/lib/modules/2.6.23.12/kernel/drivers/media/video/v4l2-common.ko): Invalid module format
WARNING: Error inserting videodev (/lib/modules/2.6.23.12/kernel/drivers/media/video/videodev.ko): Invalid module format

dmesg sagt dazu:
v4l1_compat: exports duplicate symbol v4l_compat_translate_ioctl (owned by kernel)
v4l2_common: exports duplicate symbol v4l2_norm_to_name (owned by kernel)
videodev: exports duplicate symbol video_register_device (owned by kernel)

Alle beteiligten Module waren auch im Original-Kernel als Modul übersetzt, und wurden durch die refactoring-Version ersetzt. Zum Glück scheint mein VDR auch ohne diese drei Module noch zu laufen, glücklich macht mich das aber noch nicht. Handelt es sich dabei um eine Unverträglichkeit mit den aktuellen Kerneln? Ist da irgend eine Funktionalität aus den Modulen in den Kernel gewandert? Kennt jemand eine Lösung?

Gruß,

Udo

Das deaktivieren der Multimedia-Teile hat tatsächlich funktioniert, auch wenn ich es nicht verstehe.

Beim ersten Versuch war unter "Multimedia devices" alles als Modul konfiguriert, beim zweiten Versuch habe ich dann alles deaktiviert. Beim ersten Versuch wurde jedes Modul unter drivers/media sauber durch die neuen Module ersetzt, beim zweiten Versuch existierte drivers/media natürlich noch gar nicht. Alles in allem scheinen sich die zwei Kernelpakete nicht zu unterscheiden, es ist kein Modul mehr oder weniger geworden.

Die einzige Erklärung, die noch bleibt: Obwohl alles als Modul konfiguriert war, muss wohl ein Teil trotzdem fest in den Kernel gerutscht sein...

Gruß,

Udo