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

  • Wieder diese Lücke, 3 Sekunden lang und das passiert für jeden Adapter:

    Code
    [   15.027218] DRXK driver version 0.9.4300
    [   15.079534] drxk: frontend initialized.
    [   17.123029] DVB: registering new adapter (nGene)
    [   17.123045] ngene 0000:02:00.0: DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)...


    Was passiert denn da in dieser Zeit? Von UFO werde ich kaum eine Antwort bekommen, der ignoriert mich, der Ignorant ;).
    Wie wäre es mit jasminj?


    Upps, ich meinte eigentlich diese:

    Code
    [   17.154611] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
    [   20.113856] DRXK driver version 0.9.4300


    Das Andere sind ja nur 2 Sekunden, aber nicht minder interessant.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Und hier noch einmal mit debug-Ausgaben von drxk:
    http://paste.ubuntu.com/1625189/
    Die Pausen sind zum einen beim DownloadMicrocode - ist das das Laden der Firmware?

    Code
    [   19.271527] drxk: load_microcode
    [   19.271614] drxk: DownloadMicrocode
    [   22.125606] drxk: DRXX_Open


    Und zum anderen jeweils bei

    Code
    [   17.141743] drxk: HI_Command
    [   19.171192] drxk: drxk_gate_ctrldisable

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich habe mir schon gedacht. dass das mit dem Firmware-Upload zu tun haben könnte, aber muss das wirklich so lange dauern?


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Dauert es denn bei deinem Flex-Modul so lange?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Was passiert denn da in dieser Zeit? Von UFO werde ich kaum eine Antwort bekommen, der ignoriert mich, der Ignorant ;).
    Wie wäre es mit jasminj?

    Die steckt bis über beide Ohren in was anderem und will sich eigentlich mit dem CI/CAM weiter beschäftigen.
    Sie hat auch keine HW um das nach zustellen und überhaupt keinen Tau, was da passieren könnte, weil sie sich diesen Teil noch niemals angesehen hat und keine Vermutungen anstellt, ohne etwas zu wissen ... :O


    Ich habe mir schon gedacht. dass das mit dem Firmware-Upload zu tun haben könnte, aber muss das wirklich so lange dauern?

    Nun, wenn man bei der CineS2 auch SW laden muss, was ich ja nicht weiß, dann könnte ich das nachwassern, allerdings erst nachdem mein CI/CAM 100%ig funktioniert. Mir ist wichtiger es geht überhaupt etwas und langsam, als unzuverlässig.

  • Wieder diese Lücke, 3 Sekunden lang und das passiert für jeden Adapter:

    Was passiert denn da in dieser Zeit?

    Normalerweise die Initialisierung des Tuners vor dem DRXK-Demod. Das war aber im Logfile geloescht...



    Upps, ich meinte eigentlich diese:

    Code
    [   17.154611] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
    [   20.113856] DRXK driver version 0.9.4300

    Das ist der Download der Firmware. Da gab es mal ein Problem bei synchronem Laden der Firmware bei der Device-Erkennung, die ab einer Version von udev in einen Timeout laeuft. Deshalb kann der Kernel neuerdings Firmware selbst laden (und drxk laedt asynchron, was in der Kombi wenig Sinn macht)...


    Gruss,
    S:oren

  • Dauert es denn bei deinem Flex-Modul so lange?


    Welcher Kernel, welche udev-Version?


    In neueren udev-Versionen ist der FW-Upload (während des Ladens der Treiber) "broken". Soweit ich es damals mitbekommen habe, hält der udev-Maintainer dies für richtig und normal, wofür er sich - zu Recht - den Zorn von Linus eingefangen hat. Die neuesten Kernel laden Firmware daher nun direkt - ohne udev. Bin allerdings nicht auf dem laufenden, ob und was sich in letzter Zeit in dieser Sache getan hat.


    Abhilfe, wahlweise:
    - Treiber blacklisten und später per Skript laden.
    - Ältere udev-Version verwenden.
    - Neueren Kernel verwenden.


    Edit:
    Bei mir sieht es so aus - mit ein paar zusätzlichen Ausgaben in load_microcode():


    D.h. bei mir gibt es diese Verzögerung beim Laden der Firmware nicht. Ich werde es jedoch noch einmal mit einer ngene-Bridge kontrollieren.


    CU
    Oliver

  • <OT>


    Was passiert denn da in dieser Zeit? Von UFO werde ich kaum eine Antwort bekommen, der ignoriert mich, der Ignorant ;).


    Tja, das hast Du Dir selbst zuzuschreiben. Vermutlich waren es dumme Kommentare zur 6400, die ich nicht mehr lesen wollte. Man begegnet sich eben immer zweimal im Leben... :D
    </OT>

  • Normalerweise die Initialisierung des Tuners vor dem DRXK-Demod. Das war aber im Logfile geloescht...


    Das ist der Download der Firmware. Da gab es mal ein Problem bei synchronem Laden der Firmware bei der Device-Erkennung, die ab einer Version von udev in einen Timeout laeuft. Deshalb kann der Kernel neuerdings Firmware selbst laden (und drxk laedt asynchron, was in der Kombi wenig Sinn macht)...


    Der drxk-Treiber aus meinen Repositories lädt die Firmware immer synchron während der Initialisierung. Alles andere wäre falsch. Falls man Firmware laden möchte, muß dies nämlich das erste sein, was man mit dem Chip macht. Der Treiber des Kernels ist diesbzgl. broken.


    Synchrones Laden führt bei gewissen udev/Kernel-Kombinationen zu Problemen. Abhilfe s.o.


    CU
    Oliver

  • Hallo,
    könnte man evtl. diesen Patch, der die Tasten der Fernbedienung für die TT S2-6400 FF optional direkt über das Kernel Input Device auswertbar macht in das media-build-experimental aufnehmen?
    [yaVDR 0.5] Neue DVB Treiber für TT S2-6400 erstellen und installieren


    Ich denke, das würde den Empfänger leichter nutzbar machen, wenn man nicht über das remote-Plugin gehen will (und ein paar yaVDR-Nutzer mit dieser Karte glücklich machen).


    Änderungen am TT S2-6400 Treiber sollten über das Repository von powarman gehen. In media_build_experimental möchte ich Treiber nur patchen, wenn dies unbedingt notwendig ist. Aus meiner Sicht ist der Patch ok. (Ob das Mapping stimmt, habe ich nicht kontrolliert.)


    CU
    Oliver

  • Vergesst, was ich oben über andere Fehlerursachen geschrieben habe!


    Mit ddbridge:


    Bei mir sieht es so aus - mit ein paar zusätzlichen Ausgaben in load_microcode():


    D.h. bei mir gibt es diese Verzögerung beim Laden der Firmware nicht. Ich werde es jedoch noch einmal mit einer ngene-Bridge kontrollieren.


    Da war ich wohl etwas voreilig, mit ngene habe ich diese Verzögerungen auch:


    Vermutlich liegt es daran, daß I2C-Transfers über die ngene-Bridge langsamer ablaufen. Ich werde mich diesbzgl. erkundigen.


    CU
    Oliver

  • Es gibt zwei Verzögerungen. Hier wird die Firmware geladen:

    Code
    9 15:08:11 vdr kernel: [ 8178.596071] drxk: detected a drx-3913k, spin A3, xtal 27.000 MHz
      9 15:08:12 vdr kernel: [ 8179.005931] DRXK driver version 0.9.4300


    Hier wird der Tuner-Chip initialisiert:

    Code
    9 15:08:12 vdr kernel: [ 8179.012464] drxk: frontend initialized.
      9 15:08:12 vdr kernel: [ 8179.012472] (/usr/src/media_build_experimental/v4l/ddbridge-core.c:1250) dvb_input_attach
         -> call to tuner_attach_tda18271()
      9 15:08:13 vdr kernel: [ 8180.423416] (/usr/src/media_build_experimental/v4l/ddbridge-core.c:1253) dvb_input_attach
      9 15:08:13 vdr kernel: [ 8180.423435] DDBridge 0000:02:00.0: DVB: registering adapter 1 frontend 0 (DRXK DVB-C DVB-T).


    Gruß
    e9hack

  • Hallo,
    habe heute nochmal alles übersetzt (da ein neuer Kernel bei Suse gekommen ist.) Habe auch die Info's von Jasmin gelesen. Vielen Dank Jasmin. Das adapter_alloc=3
    Habe ich mal auskommentiert. Den echo Befehle habe ich mit 01 02 ausgeführt. Ich hoffe das war richtig, das TAB1 ist leer.


    Leider bleibt der Bildschirm dunkel, mit kaffein habe auch beide Empfänger probiert. Gibt es hier noch etwas was man probieren kann?


    Franz


    Hier das log:


    Feb 10 22:13:03 linux-wyeu kernel: [ 142.685549] cxd2099: module is from the staging directory, the quality is unknown, you have been warned.
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687316] WARNING: You are using an experimental version of the media stack.
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687317] As the driver is backported to an older kernel, it doesn't offer
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687318] enough quality for its usage in production.
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687318] Use it with care.
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687319] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org:(
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687319] 8b2aea7878f64814544d0527c659011949d52358 [media] em28xx: prefer bulk mode on webcams
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687320] a3efa1cc0e067675ffa2d2c357cbe1da0db4653b [media] em28xx: make the logs reflect the specific chip name
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687321] aa51496b21542855e779a78bf33384002f01acb6 [media] em28xx: display the isoc/bulk mode
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687321] experimental: 9b79c0d0acf1607158e1bdb70fe913059894bfd5 experimental: Add workaround for CAM write errors.
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687322] ngene-octopus-test: a8742d5952072f2237cdf28ae4cbb78fa6039f80 ddbridge: Add Digital Devices Cine S2 V6.5
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687323] v4l-dvb-saa716x: a605fbd008412f3a308f30b8b2f536bd2143fbcb aa716x_ff: print decimal digits for firmware version.
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687778] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687805] DDBridge driver detected: Digital Devices Octopus CI single
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687828] HW 00010006 REG 00010002
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.687882] DDBridge 0000:01:00.0: irq 55 for MSI/MSI-X
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.688554] Port 0 (TAB 1): NO MODULE
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.690117] Port 1 (TAB 2): DUAL DVB-C/T
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.690122] Port 2 (TAB 3): CI internal
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.690616] DVB: registering new adapter (DDBridge)
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.690619] DVB: registering new adapter (DDBridge)
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.690620] DVB: registering new adapter (DDBridge)
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.693343] stv0367 found
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.952391] tda18212dd: ChipID 4724
    Feb 10 22:13:03 linux-wyeu kernel: [ 142.952822] tda18212dd: PowerState 01
    Feb 10 22:13:03 linux-wyeu kernel: [ 143.087365] DDBridge 0000:01:00.0: DVB: registering adapter 0 frontend 0 (STV0367 DVB-C DVB-T)...
    Feb 10 22:13:03 linux-wyeu kernel: [ 143.088305] stv0367 found
    Feb 10 22:13:03 linux-wyeu kernel: [ 143.346716] tda18212dd: ChipID 4724
    Feb 10 22:13:03 linux-wyeu kernel: [ 143.347146] tda18212dd: PowerState 00
    Feb 10 22:13:03 linux-wyeu kernel: [ 143.603792] DDBridge 0000:01:00.0: DVB: registering adapter 1 frontend 0 (STV0367 DVB-C DVB-T)...
    Feb 10 22:13:03 linux-wyeu kernel: [ 143.605832] redirect: 01, 02
    Feb 10 22:13:08 linux-wyeu kernel: [ 148.597846] slot reset 0
    Feb 10 22:13:09 linux-wyeu kernel: [ 149.473856] dvb_ca adapter 2: DVB CAM detected and initialised successfully

  • Das adapter_alloc=3
    Habe ich mal auskommentiert.


    Keine gute Idee. Teste, ob es mit adapter_alloc=3 funktioniert.


    CU
    Oliver

  • Hallo,
    habe das wieder eingebaut, aber leider auch ohne Erfolg. Alles dunkel bis auf ZDF und ARD. Hier nochmal das log. Es hat sich nichts verändert. Ist den der echo Befhel korrekt ?


    Gruss
    Franz
    ll /dev/dvb/adapter0/
    insgesamt 0
    crw-rw----+ 1 root video 212, 8 11. Feb 23:10 ca0
    crw-rw----+ 1 root video 212, 0 11. Feb 23:10 demux0
    crw-rw----+ 1 root video 212, 4 11. Feb 23:10 demux1
    crw-rw----+ 1 root video 212, 1 11. Feb 23:10 dvr0
    crw-rw----+ 1 root video 212, 5 11. Feb 23:10 dvr1
    crw-rw----+ 1 root video 212, 3 11. Feb 23:10 frontend0
    crw-rw----+ 1 root video 212, 7 11. Feb 23:10 frontend1
    crw-rw----+ 1 root video 212, 2 11. Feb 23:10 net0
    crw-rw----+ 1 root video 212, 6 11. Feb 23:10 net1
    crw-rw----+ 1 root video 212, 9 11. Feb 23:10 sec0




    # tail -f /var/log/messages
    Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sinks
    Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sources
    Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sinks
    Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sources
    Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sinks
    Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sources
    Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sinks
    Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sources
    Feb 11 23:10:19 linux-wyeu sudo: root : TTY=pts/2 ; PWD=/home/tv/media_build_experimental/v4l ; USER=tv ; COMMAND=/usr/bin/pacmd list-sinks
    Feb 11 23:10:29 linux-wyeu su: (to root) tv on /dev/pts/0
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.087067] cxd2099: module is from the staging directory, the quality is unknown, you have been warned.
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.088807] WARNING: You are using an experimental version of the media stack.
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.088809] As the driver is backported to an older kernel, it doesn't offer
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.088811] enough quality for its usage in production.
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.088812] Use it with care.
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.088813] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org:(
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.088814] 8b2aea7878f64814544d0527c659011949d52358 [media] em28xx: prefer bulk mode on webcams
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.088815] a3efa1cc0e067675ffa2d2c357cbe1da0db4653b [media] em28xx: make the logs reflect the specific chip name
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.088817] aa51496b21542855e779a78bf33384002f01acb6 [media] em28xx: display the isoc/bulk mode
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.088818] experimental: 9b79c0d0acf1607158e1bdb70fe913059894bfd5 experimental: Add workaround for CAM write errors.
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.088820] ngene-octopus-test: a8742d5952072f2237cdf28ae4cbb78fa6039f80 ddbridge: Add Digital Devices Cine S2 V6.5
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.088822] v4l-dvb-saa716x: a605fbd008412f3a308f30b8b2f536bd2143fbcb aa716x_ff: print decimal digits for firmware version.
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.089316] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.089389] DDBridge driver detected: Digital Devices Octopus CI single
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.089436] HW 00010006 REG 00010002
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.089496] DDBridge 0000:01:00.0: irq 53 for MSI/MSI-X
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.090150] Port 0 (TAB 1): NO MODULE
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.091649] Port 1 (TAB 2): DUAL DVB-C/T
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.091652] Port 2 (TAB 3): CI internal
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.092138] DVB: registering new adapter (DDBridge)
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.094967] stv0367 found
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.347717] tda18212dd: ChipID 4724
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.348144] tda18212dd: PowerState 01
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.482427] DDBridge 0000:01:00.0: DVB: registering adapter 0 frontend 0 (STV0367 DVB-C DVB-T)...
    Feb 11 23:10:52 linux-wyeu kernel: [ 139.483267] stv0367 found
    Feb 11 23:10:53 linux-wyeu kernel: [ 139.737674] tda18212dd: ChipID 4724
    Feb 11 23:10:53 linux-wyeu kernel: [ 139.738090] tda18212dd: PowerState 00
    Feb 11 23:10:53 linux-wyeu kernel: [ 139.994895] DDBridge 0000:01:00.0: DVB: registering adapter 0 frontend 0 (STV0367 DVB-C DVB-T)...
    Feb 11 23:10:53 linux-wyeu kernel: [ 139.997124] redirect: 01, 02
    Feb 11 23:10:58 linux-wyeu kernel: [ 144.989337] slot reset 0
    Feb 11 23:10:59 linux-wyeu kernel: [ 145.865441] dvb_ca adapter 0: DVB CAM detected and initialised successfully
    Feb 11 23:11:05 linux-wyeu kernel: [ 151.945913] IPv4: martian source 255.255.255.255 from 192.168.178.25, on dev eth1
    Feb 11 23:11:05 linux-wyeu kernel: [ 151.945919] ll header: 00000000: ff ff ff ff ff ff 00 11 32 0c 45 68 08 00 ........2.Eh..

  • Ist den der echo Befehl korrekt ?

    Bei mir sieht das so aus:
    Port 0 (TAB 1): DUAL DVB-S2
    Port 1 (TAB 2): NO MODULE
    Port 2 (TAB 3): CI
    Und funktioniert mit: redirect: 00, 02
    Bei dir ist es :
    Port 0 (TAB 1): NO MODULE
    Port 1 (TAB 2): DUAL DVB-C/T
    Port 2 (TAB 3): CI internal
    Guckst du hier for Details.
    Der Parameter müsste also 02 02 sein, denke ich. Allerdings spricht der Artikel von der CineS2 V6.0
    Hier findest du noch mehr dazu. Probiere es mal aus.


    Ich sehe keine Ausgaben vom VDR. Du scheinst ein anderes Programm zu benutzen. Mit dem VDR würde man die Initialisierung am Session Layer des CAM sehen. Da kommt dann die Ausgabe, dass es sich um ein XXX Modul handelt. Du kannst aber auch mit dem dvb-core Modul Parameter cam_debug=1, das Logging des Treibers anwerfen. Allerdings ist der sehr gesprächig. Man sieht dann aber, ob das Modul erkannt wird und ob damit gesprochen wird.
    Wenn du die Logs postets, dann vielleicht besser mit pastbinit.


    LG
    Jasmin

  • Ja, ich möchte den VDR installieren, keine Frage. Aber ich teste die Sache mit kaffein. Ich habe die echo 02 02 heute getested ohne Erfolg. Also mit:


    KERNEL=="ddbridge0", ACTION=="add", SUBSYSTEM=="ddbridge", RUN+="/etc/udev/ddbridge_redirect '02 02'"


    Mit dem gnutv -cammenu bekomme ich die Infos von der Karte. Allerdings auch: en50221_stdcam_llci_poll: Error reported by stack:-3 was auch immer das bedeutet.


    Ich versuche mal am Wochenende den Text zu verstehen. Ich habe das wohl nicht korrekt verstanden.


    Den Tipp mit dem pastbinit nehme ich gerne an, wusste nichts von dem Tool. Bin noch recht neu in diesen Foren.


    Gruss


    Franz

  • Ja, ich möchte den VDR installieren, keine Frage. Aber ich teste die Sache mit kaffein. Ich habe die echo 02 02 heute getested ohne Erfolg. Also mit:
    KERNEL=="ddbridge0", ACTION=="add", SUBSYSTEM=="ddbridge", RUN+="/etc/udev/ddbridge_redirect '02 02'"

    Ich nehme an im Syslog war die redirect Ausgabe vom Kernel zu sehen? Der Treiber hat leider keine Rücklesemöglichkeit für diesen Parameter im SysFS. Ich wollte das nachbauen, aber dann hätte ich mir das in einer neuen Variablen merken müssen, weil der Treiber das nur einmal einstellt, soweit ich mich erinnere. War mir dann doch nicht so wichtig ... .


    Mit dem gnutv -cammenu bekomme ich die Infos von der Karte. Allerdings auch: en50221_stdcam_llci_poll: Error reported by stack:-3 was auch immer das bedeutet.

    Ich hab das mal gegoogelt und mich dann weiter gehangelt und das und das und das gefunden (musst die Funktionen/Symbole dort suchen). Das ist jetzt nur ein guess von mir, aber ich denke es ist ein Timeout.
    Ich habe dir den Tipp mit dem "cam_debug=1" im letzten Post gegeben. Wenn dir der zu gesprächig ist, dann musst eben die entsprechenden Zeilen im Treiber auskommentieren. Das sind vor allem die ioctl Aufrufe. Aber man kommt auch so durch, weil man das syslog ja später genauer analysieren kann.


    Den Tipp mit dem pastbinit nehme ich gerne an, wusste nichts von dem Tool. Bin noch recht neu in diesen Foren.

    Hab ich auch erst hier, vor 2 Wochen gelernt ;)


    LG
    Jasmin

  • Der Treiber hat leider keine Rücklesemöglichkeit für diesen Parameter im SysFS. Ich wollte das nachbauen, aber dann hätte ich mir das in einer neuen Variablen merken müssen, weil der Treiber das nur einmal einstellt, soweit ich mich erinnere.


    Falls du das doch mal machen willst, bedenke, dass sich das redirect mehrmals aufrufen lässt, weil es ja auch mehrere Tuner/CIs geben kann.


    Lars

  • Nochmal was ganz anderes was mir gerade einfällt. Mir ist aufgefallen, dass bei einem make -jN mit N > 1 die Patcherei kräftig auf die Nase fällt, weil dann zwei Make-Threads gleichzeitig versuchen zu patchen. Das scheint irgendwie nicht atomar gelöst zu sein. Ich weiß nicht warum das vorher nie aufgefallen ist. Vielleicht liegt es daran, dass mein Desktop ziemlich zügig zu werke geht. Aus Zeitgründen kann ich leider keine Patches für das Problem liefern.


    Da mich UFO nach wie vor ignoriert mag mich vielleicht jemand quoten?


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

Jetzt mitmachen!

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