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

  • After make untar do:



    Code
    1. cd linux
    2. patch -p1 < path/to/pci_dma_supported.diff
    3. cd ..
    4. make distclean
    5. make allyesconfig ## or make menuconfig
    6. make
    7. make install


    That's it.

    Thanks for your help. When I try to perform this code:


    Code
    1. patch -p1 < path/to/pci_dma_supported.diff


    I have the following answer:


    Code
    1. [userssh@pcsalon media_build_experimental]$ sudo patch -p1 < /home/userssh/pci_dma_supported.diffcan't find file to patch at input line 5Perhaps you used the wrong -p or --strip option?The text leading up to this was:--------------------------|diff --git a/drivers/media/pci/cx23885/cx23885-core.c b/drivers/media/pci/cx23885/cx23885-core.c|index 3bd386c..abd15b3 100644|--- a/drivers/media/pci/cx23885/cx23885-core.c|+++ b/drivers/media/pci/cx23885/cx23885-core.c--------------------------File to patch:
  • zofiel : you didn't do the "cd linux".


    Gerald

    yeah, thanks a lot. Patch applied.


    This patch doesn't fix the following error, Is'n It?




    How I can fix It? I have a Skystar 2 express HD and i think that this driver is the only than works with my device.


    Thanks a lot for your help

  • zofiel :

    Hi,


    hab ich hier auch mit kernel 4.3


    CU
    9000h


    This is posted just one page back. I guess it wil solve your issue.
    Do you even read this thread at all?

  • zofiel :


    This is posted just one page back. I guess it wil solve your issue.
    Do you even read this thread at all?


    First of all, thanks a lot for all forum help.


    yes, I come this to forum following this error via Google. As you can see, I'm very newbie with patchs, and I don't speak German, so I'm reading the thread but It's very difficult. Sorry for this Offtopic.


    I'm reading your quote but I don't know how


    zofiel :


    This is posted just one page back. I guess it wil solve your issue.
    Do you even read this thread at all?


    First of all, thanks a lot for all forum help.


    yes, I come this to forum following this error via Google. As you can see, I'm very newbie with patchs, and I don't speak German, so I'm reading the thread but It's very difficult. Sorry for this Offtopic.


    I'm reading your quote but I don't know how to apply this config, so any little help is welcome. :)

  • zofiel :
    sorry, I did not realise that you are extremely new to this.
    So here's how to do it:


    like before, after make untar, do


    Code
    1. cd linux
    2. patch -p1 < path/to/pci_dma_supported.diff
    3. patch -p1 < path/to/adp1653.diff
    4. cd ..
    5. make distclean
    6. make allyesconfig ## or make menuconfig
    7. make
    8. make install


    Cheers,
    Tycho.

  • Mal eine kurze Frage, ist es möglich die MAX S8 parallel noch zu herkömmlichen Cine Duoflex-Karten im selben Rechner zu betreiben?


    Oder könnte das zu Problemen führen?


    Danke,

  • Hi, I'm using an Octopus with a dual S2 board and was using the 0.5 for a few years without problem. Upgrading to a new kernel I decided to give the latest 0.9.18 a try but for some reason only vertical polarized channels seem to work. Anybody experienced this yet? The only symptoms I see are very very high BER, and 0 or very low signal strength and SNR.


    version: 0.9.18
    srcversion: B3FB489B38DDF7D19A16E2B


    What supprises me is that the vertical channels work. While this could in theory be a LNB problem (water/moisture inside the LNB? I noticed the change with the different version so thinking of this at first.

  • I have a small update on this. It turns out the LNB is broken, de Horizontals no longer work. I have thus far excluded the cables and used a different LNB. With a different LNB it worked for a day, after a day, the signal strength dropped from 80% to 20% on the H and a day later, de V also had a drop from 80% to 20%. Using the original M7 tuner also shows the same symptoms on the LNB now.


    Is it possible that for some reason the 0.9.8.1 driver can potentially kill LNB's? I've been using the 0.5 driver for 3 years now and never had a problem and within a week of using the 0.9.8 driver I killed the H on my duo lnb and the H and V on my inverto black LNB. For now, I will connect the duo lnb again to the 0.9.8 driver and see how long it takes before the V is killed also here (since the LNB is half-useless. If the V also dies, i'll roll back the 0.9.8 driver ... and keep using the 0.5

  • Hallo zusammen,


    ich bekomme I2C timeouts trotz "options ddbridge msi=0". Jemand 'ne Idee warum das so ist? Hardware ist eine DD Cine S2 v6.5 plus DuoFlex S2. Läuft unter ESXi 6.0 mit VT-d Passthrough.


    Code
    1. root@vdr:~# uname -a
    2. Linux vdr 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux


    Code
    1. root@vdr:~# cat /etc/modprobe.d/ddbridge.conf
    2. options ddbridge msi=0


    dmesg Auszug wenn ddbridge geladen wird:


    dmesg Auszug mit I2C timeouts:

    Code
    1. root@vdr:~# dmesg -T|tail -8
    2. [Fri Jan 22 17:12:31 2016] DDBridge I2C timeout, card 0, port 0, link 0
    3. [Fri Jan 22 17:12:31 2016] ddbridge 0000:03:00.0: DDBridge IRS 00000f03
    4. [Fri Jan 22 17:12:32 2016] DDBridge I2C timeout, card 0, port 1, link 0
    5. [Fri Jan 22 17:12:32 2016] ddbridge 0000:03:00.0: DDBridge IRS 00000000
    6. [Fri Jan 22 18:06:02 2016] DDBridge I2C timeout, card 0, port 0, link 0
    7. [Fri Jan 22 18:06:02 2016] ddbridge 0000:03:00.0: DDBridge IRS 00000e03
    8. [Fri Jan 22 18:06:02 2016] DDBridge I2C timeout, card 0, port 1, link 0
    9. [Fri Jan 22 18:06:02 2016] ddbridge 0000:03:00.0: DDBridge IRS 00000000


    Woran kann das liegen?

    Produktiv: VDR "headless" Server:

    • Fujitsu-Siemes Scenic L Tower, Intel PIII 933 MHz, Intel 815 Chipsatz, 5 x PCI, 256 MB RAM, 500 GB IDE für OS und /home, 1,5 TB an Delock PCI SATA Controller für /video, 3 x Budget TT 1401, on-board 10/100 Netzwerk, on-board Grafik,
    • Debian, VDR 2.0.1 mit ffnetdev, epgsearch, streamdev-server und live Plugins

    Im Aufbau: VDR "headless" Server:

    • Whitebox mit Supermicro X10SLL+-F, Xeon Prozessor, 16 GB RAM als ESXi Host, Debian VM für VDR, Digital Devices Cine S2 mit VT-d Passthrough an die VM
    • Debian, VDR 2.2 mit ffnetdev, epgsearch, streamdev-server und live Plugins

    Client: Laptop, Windows und OS X, VLC Media Player


  • ich bekomme I2C timeouts trotz "options ddbridge msi=0". Jemand 'ne Idee warum das so ist? Hardware ist eine DD Cine S2 v6.5 plus DuoFlex S2. Läuft unter ESXi 6.0 mit VT-d Passthrough.

    Ich habe jetzt mal MSI im Kernel abgeschaltet:


    Code
    1. root@vdr:~# cat /proc/cmdline
    2. BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=98334508-4299-4072-8870-04ee745a0fde ro pci=nomsi quiet


    bekomme aber immer noch Meldungen:


    Code
    1. root@vdr:~# dmesg -T|tail -8
    2. [Sun Jan 31 02:57:22 2016] DDBridge I2C timeout, card 0, port 0, link 0
    3. [Sun Jan 31 02:57:22 2016] ddbridge 0000:03:00.0: DDBridge IRS 00000c03
    4. [Sun Jan 31 02:57:22 2016] DDBridge I2C timeout, card 0, port 1, link 0
    5. [Sun Jan 31 02:57:22 2016] ddbridge 0000:03:00.0: DDBridge IRS 00000000
    6. [Sun Jan 31 03:02:19 2016] DDBridge I2C timeout, card 0, port 0, link 0
    7. [Sun Jan 31 03:02:19 2016] ddbridge 0000:03:00.0: DDBridge IRS 00000d03
    8. [Sun Jan 31 03:02:19 2016] DDBridge I2C timeout, card 0, port 1, link 0
    9. [Sun Jan 31 03:02:19 2016] ddbridge 0000:03:00.0: DDBridge IRS 00000000


    Wie kann das sein? Oder haben die I2C timeouts nix mit MSI zu tun?

    Produktiv: VDR "headless" Server:

    • Fujitsu-Siemes Scenic L Tower, Intel PIII 933 MHz, Intel 815 Chipsatz, 5 x PCI, 256 MB RAM, 500 GB IDE für OS und /home, 1,5 TB an Delock PCI SATA Controller für /video, 3 x Budget TT 1401, on-board 10/100 Netzwerk, on-board Grafik,
    • Debian, VDR 2.0.1 mit ffnetdev, epgsearch, streamdev-server und live Plugins

    Im Aufbau: VDR "headless" Server:

    • Whitebox mit Supermicro X10SLL+-F, Xeon Prozessor, 16 GB RAM als ESXi Host, Debian VM für VDR, Digital Devices Cine S2 mit VT-d Passthrough an die VM
    • Debian, VDR 2.2 mit ffnetdev, epgsearch, streamdev-server und live Plugins

    Client: Laptop, Windows und OS X, VLC Media Player

  • Wollte mich an dieser Stelle einfach mal bedanken.


    Code
    1. options ddbridge msi=0


    In /etc/modprobe.d zu laden hat es bei mir wohl gebracht! Davor (ich nutze eine Cine S2 6.5 mit Duo Flex S2) hat es mir immer zwei der vier Karten mit den I2C-Timeout Meldungen im syslog zerbröselt, was zum Absturz des VDR und des Systems (runterfahren ging nicht mehr, musste das System mittels der Powertaste stromlos machen) führte. Selbst, wenn man ein Reboot ging, die Karte 3 und 4 kamen nicht mehr hoch, dazu musste erstmal stromlos gemacht werden.


    Komischerweise habe ich den Effekt erst seit ein paar Tagen, die Karten aber schon seit 3 Monaten verbaut. Verstehe, wer wolle...

    Hardware: Intel E5300, Gigabyte GA-EP41-UD3L, 4GB DDR2-RAM, 60GB 2.5" System, 3TB 3.5" Daten, L4M Cine S2 V6.5 DuoFlex S2 V4, Samsung 46" LED-LCD TV
    Software: yaVDR mit diversen Plugins und XBMC
    Ambilight: SEDU Board, 112 * WS2801 LEDs, boblight/vdr-plugin-seduatmo


    Pro-Taucher - Tauchplätze weltweit

  • Since kernel 4.4 I'm having the following errors



    the code is too long, so you can follow It in http://pastebin.com/7ii94LwQ


    Any idea? Thanks for your help

  • After update to new kernel i get the followin errors:


    rgu@tv-server:~/media_build_experimental$ make
    make -C /home/rgu/media_build_experimental/v4l
    make[1]: Verzeichnis „/home/rgu/media_build_experimental/v4l“ wird betreten
    creating symbolic links...
    make -C firmware prep
    make[2]: Entering directory '/home/rgu/media_build_experimental/v4l/firmware'
    make[2]: Leaving directory '/home/rgu/media_build_experimental/v4l/firmware'
    make -C firmware
    make[2]: Entering directory '/home/rgu/media_build_experimental/v4l/firmware'
    make[2]: Nothing to be done for 'default'.
    make[2]: Leaving directory '/home/rgu/media_build_experimental/v4l/firmware'
    Kernel build directory is /lib/modules/4.4.0-6-generic/build
    make -C ../linux apply_patches
    make[2]: Entering directory '/home/rgu/media_build_experimental/linux'
    Patches for 4.4.0-6-generic already applied.
    make[2]: Leaving directory '/home/rgu/media_build_experimental/linux'
    make -C /lib/modules/4.4.0-6-generic/build SUBDIRS=/home/rgu/media_build_experimental/v4l modules
    make[2]: Entering directory '/usr/src/linux-headers-4.4.0-6-generic'
    CC [M] /home/rgu/media_build_experimental/v4l/adp1653.o
    /home/rgu/media_build_experimental/v4l/adp1653.c: In function 'adp1653_of_init':
    /home/rgu/media_build_experimental/v4l/adp1653.c:468:20: error: too few arguments to function 'devm_gpiod_get'
    pd->enable_gpio = devm_gpiod_get(&client->dev, "enable");
    ^
    In file included from /home/rgu/media_build_experimental/v4l/adp1653.c:39:0:
    include/linux/gpio/consumer.h:73:32: note: declared here
    struct gpio_desc *__must_check devm_gpiod_get(struct device *dev,
    ^
    scripts/Makefile.build:264: die Regel für Ziel „/home/rgu/media_build_experimental/v4l/adp1653.o“ scheiterte
    make[3]: *** [/home/rgu/media_build_experimental/v4l/adp1653.o] Fehler 1
    Makefile:1396: recipe for target '_module_/home/rgu/media_build_experimental/v4l' failed
    make[2]: *** [_module_/home/rgu/media_build_experimental/v4l] Error 2
    make[2]: Leaving directory '/usr/src/linux-headers-4.4.0-6-generic'
    Makefile:51: die Regel für Ziel „default“ scheiterte
    make[1]: *** [default] Fehler 2
    make[1]: Verzeichnis „/home/rgu/media_build_experimental/v4l“ wird verlassen
    Makefile:28: die Regel für Ziel „all“ scheiterte
    make: *** [all] Fehler 2
    rgu@tv-server:~/media_build_experimental$


    Any ideas?