Update: Optimierter av7110 Treiber

  • :moin


    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

    SW: c't VDR mit e-tobi, vdr 1.4.x, Kernel 2.6.18.1 (PowerNow! Patch + HG Treiber), Bootzeit: 45s
    HW: PC-Chips M811, AMD Geode NX 1750+@1.125V, 512MB RAM, 1GB CF, 100MBit LAN, DVD-ROM, TT2.3 modded (4MB + S-Video, IR, S/PDIF über J2), 1 x TT-Budget S1401, 2 x TT-Budget, 256x64 GVFD, WakeUP + 4x40 LCD
    Gehäuse: 8mm Alu, Netzteil: 300W passiv Umbau, Verbrauch|CPU|Gehäuse: @533Mhz(Idle) 59W|37°C|33°C, @1400Mhz(100%) 81W|46°C|41°C

  • Hi,


    alles Relevante steht doch im ersten Posting dieses Threads!


    Im "offiziellen" HG-Treiber sind die Patches zwar nicht enthalten, aber ich pflege das Repository
    http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring


    Dieses entspricht dem aktuellem HG-Treiber + av7110-Patches.


    Wenn ich mal wieder Zeit habe (seufz), werde ich auch weiter daran arbeiten.


    Momentan komme ich einfach nicht dazu. Habe berufsmäßig viel zu tun, und immer wenn ich anfangen möchte, kommen irgendwelche anderen Treibergeschichten dazwischen. :(


    Und das Remote-Plugin wartet auch schon wieder auf einen Update...


    CU
    Oliver

  • 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

    Debian server [ AMD Athlon(tm) 64 Processor 3000+ 3*Nova SE2 1* FF muss nachschauen CI + alphacrypt Soft raid5 549G]
    Clients [2 * MVP mit vomp 1 * MacBook Pro VLC streaming 1 * VOMP for windows]

  • 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

    Debian server [ AMD Athlon(tm) 64 Processor 3000+ 3*Nova SE2 1* FF muss nachschauen CI + alphacrypt Soft raid5 549G]
    Clients [2 * MVP mit vomp 1 * MacBook Pro VLC streaming 1 * VOMP for windows]

  • 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?

    VDR: Eigenbau "LINVDR 0.8", Linux 2.6.23.12-K7 mit PowerNOW! manual Patch , VDR 1.4.7 mit Elchi- und Liemikuutio-Patch, gcc 4.2
    Hardware: ASROCK K7S41GX, AMD Geode NX 1750 - 512 MB RAM - 400 GB HD IDE - Philips PBDV1640 - TT DVB-S Premium 1.5 mit AV-Board + TT DVB-S Budget in Antec Aria Gehäuse

    Edited once, last by IO470E ().

  • 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

  • Quote

    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).


    Code
    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 :

    Code
    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


  • Iirc hat sich beim videobuf-Zeug so einiges geändert.


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


    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.)


    CU
    Oliver

  • Quote

    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.


    Quote

    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

  • Quote

    Original von viking


    Im kernel sind die DVB treiber einkompiliert, kann das der grund sein ?


    Klar. Wenn man externe Treiber verwenden möchte, darf man auf keinen Fall entsprechende Module in den Kernel einkompilieren. Am sichersten ist es, v4l/dvb Support im Kernel komplett zu deaktivieren. (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. Ist halt eine zusätzliche Fehlerquelle.)


    Quote


    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)


    Glaube nicht, daß dieses Problem distributionsspezifisch ist.


    CU
    Oliver

  • Quote

    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?

    HW: Gigabyte EP41-UD3L | Core2Duo 7400 | 2GB Kingston | MSI N220GT-MD1GZ (passiv) | L4M-Twin S2 ver 6.5 mit Flex S2 | Silverstone LC16M mit iMON VFD | Samsung LE46B750
    SW: Xubuntu 14.04 3.13.0-24 | NVIDIA 304.117 | vdr 2.1.6 | softhddevice | inputlirc | lcdproc

  • Quote

    Original von goldbär


    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?


    Ja. Es ist trotzdem keine saubere Lösung, denn beim nächsten Kernelbauen wird der Kernel die reinkopierten Module überschreiben. Eine gute Möglichkeit, sich selbst ein Bein zu stellen...


    CU
    Oliver

  • Quote

    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


  • Bei mir gibt's keinerlei Warnungen mit 2.6.23.12.


    Sieht so aus, als ob Module des Kernels mit denen des Treibers gemischt wurden oder eines der Module fest in den Kernel einkompiliert wurde.


    Um solche Probleme sicher zu vermeiden, sollte man v4l/dvb im Kernel komplett deaktivieren.
    Dann kommen alle Module garantiert vom kompilierten Treiber...


    CU
    Oliver

  • 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

  • Quote

    Original von Urig
    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...


    Iirc gab's da schon mal so ähnliche Probleme. Möglicherweise wurde das Check-Skript auch durch Module des Kernels verwirrt.


    Egal, durch das Deaktivieren des Kerneltreibers ist man garantiert auf der sicheren Seite:
    Falls man vergessen hat, ein Modul zu übersetzen, erkennt man dies sofort. Andernfalls bleibt evtl. ein altes Modul des Kernels erhalten....


    CU
    Oliver

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!