CICAM hängt sich ab

  • Vielleicht fällt ja jemandem hierzu etwas ein.


    In meinem VDR sind insgesamt drei Karten verbaut. CAM1 und CAM3 sind jeweils mit einem Alphacrypt-Modul bestückt. Der VDR empfängt Kabel und SAT. Schaltet man nun auf einen Kanal, der CAM1 (SAT) verwendet, geht nach einem Zurückschalten auf einen Kanal der CAM3 benötigt dieser CAM nicht. Erst nach Rücksetzen des CAM über das VDR-Menü, Schalten auf einen uncodierten Kanal dieser Karte und dann auf den codierten Kanal funktioniert es wieder. Ich kann zwar mit diesem etwas chaotischen Ablauf leben, will aber nicht einsehen, warum dies so ist.
    VDR ist 1.5.17 (das Problem trat aber auch schon bei 1.4 aufl)


    V4L ist aus dem hg-Repositorium und hat Version [2.6.25], aber auch vorherige Versionen zeigten das beschriebene Problem.



    Hier die "dmesg":


    Aus dem Log:

    ASRock P67 Extreme6, Intel core i7-2600, 16GB DDR-3 RAM, Ubuntu 18.04, VDR 2.4.0, Digital Devices Max M4

    RaspberryPi 3, Kodi 18.1, PVR

    Einmal editiert, zuletzt von gdoerrhoefer ()

  • (Sorry for replying in English. My skills in writing German are not what they used to be ;))


    Zitat

    Originally posted by gdoerrhoefer

    Code
    Linux version 2.6.23.12-slh-smp-2 [...]
    
    
    Mar  7 20:57:26 siduxbox kernel: dvb_ca adapter 1: DVB CAM detected and initialised successfully
    Mar  7 20:57:46 siduxbox kernel: dvb_ca adapter 1: CAM tried to send a buffer larger than the ecount size!


    I encountered that problem when I moved from an Althlon64-based machine (old, socket 754, single core) to a shiny new Core 2 Duo setup. With MythTV rather than VDR, but that should make little difference -- this is a kernel service, after all.


    The "CAM tried to send a buffer larger than the ecount size!" problem I had with my Alphacrypts disappeared when I started running the kernel in nosmp mode. That effectively downgraded my machine to being single-core, but it did make the DVB-CAM stuff stable.


    One might be forgiven for thinking the CAM support in the Linux kernel is not (yet) completely SMP-capable.

  • Zitat

    The "CAM tried to send a buffer larger than the ecount size!" problem I had with my Alphacrypts disappeared when I started running the kernel in nosmp mode. That effectively downgraded my machine to being single-core, but it did make the DVB-CAM stuff stable.


    Danke für den Tipp. In der Tat ist es ein Problem mit dem SMP - allerdings funktioniert bei mir (Sidux) die Option "nosmp" nicht, da dabei noch andere Funktionen abgeschaltet werden und das System damit nicht mehr bootet. Aber die Option "maxcpus=1" funktioniert.



    Code
    title		Debian GNU/Linux, kernel 2.6.23.12-slh-smp-2 nosmp
    root		(hd0,1)
    kernel		/vmlinuz-2.6.23.12-slh-smp-2 \
     root=UUID=2876dccf-4b5b-47b8-8632-c10d207a09b4 ro maxcpus=1\
     quiet vga=791 SELINUX_INIT=NO 
    initrd		/initrd.img-2.6.23.12-slh-smp-2


    Damit konnte ich die Probleme nicht mehr beobachten.

    ASRock P67 Extreme6, Intel core i7-2600, 16GB DDR-3 RAM, Ubuntu 18.04, VDR 2.4.0, Digital Devices Max M4

    RaspberryPi 3, Kodi 18.1, PVR

  • Hallo Leute. Ich glaube ich habe hier das selbe problem. ich bekomme immer wieder folgende fehler: kernel: dvb_ca adapter 0: CAM tried to send a buffer larger than the link buffer size (192 > 128)!. Gibt es vielleicht noch eine andere Möglichkeit als einfach nur eine CPU zu nutzen?

  • Bei mir funktioniert auch folgende Variante:
    1) Ganz normal booten parameter maxcpus nicht angeben.
    2) vdr mit taskset 0x00000001 vdr ....... starten.


    Mit taskset wird der vdr prozess - in diesem fall - an den ersten core gebunden, Seitdem habe ich keine Probleme mehr mit ecount size.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!