Beiträge von das-d

    Erklärung nicht, aber Mutmaßung.


    Wenn CIR-wakeup aus S5 funktionieren soll, muss es im BIOS aktiv sein, meist ist es deaktiviert. Beim DH67BL ist es bsw. so, es gibt aber keine interne BIOS Option, um dies zu aktivieren. Also braucht man externe Tools, die dann das Register im CMOS Ram aktiv setzen können. Windows mit den CIR Treibern kann dies, tut dies und so funktioniert dann danach auch wakeup aus S5. Vielleicht können mittlerweile auch Linux Treiber oder Tools dieses Register setzen.
    BIOS Funktion wäre natürlich die beste Option, meist machen die Hersteller aber nur das Nötigste, aber die Hoffnung stirbt zuletzt.


    Gruß Fr@nk


    Hallo Frank,
    danke für den kleinen Einschub, dann hatte ich das aus dem laufenden Thread wohl doch richtig herausgelesen.


    Bei meinem DH67CF Board gibt es auch "nur" die Möglichkeit den CIR Header zu aktivieren, seperate Einstellungen für die Möglichkeiten des WakeUps bestehen nicht. Das war aber wohl zu erwarten, da ich denke dass sich die Boards in den Möglichkeiten im BIOS nur marginal Unterscheiden dürften. BIOS Update habe ich auch noch durchgeführt aber damit hat sich noch keine Änderung ergeben.


    Um an die Register oder möglichkeiten heranzukommen bräuchte man einen guten Einblick in die Windows Treiber oder Dokumentationen. Sehr aufwendig, da werden wir nichts erreichen. Fraglich ist natürlich wer den Nuvoton Treiber für Windows und wer für Linux entwickelt hat und warum die Eigenschaften und Möglichkeiten unterschiedlich sind.


    Ich werde heute mal das Linux-media-dkms installieren und sehen ob es bei mir Wirkung zeigt.


    Gruß Daniel

    Warum soll denn linux-media-dkms für die Wakeup Funktionen einen Unterschied machen das Verstehe ich nicht. Jemand eine Erklärung?


    Ich kämpfe noch mit meinem Board werd aber sehen obs noch ein BIOS Update gibt.


    Gruß Daniel

    Hallo Jungs,
    ich habe jetzt auf Fedora 16 umgestellt und somit auch auf nen 3.1.2.0.7 Kernel oder so. Bin mir nimmer sicher.


    Nun liegt das an euren Skripten oder Fedora das bei mehreren installierten Kernels ein beliebiger (in dem Fall war es der alte) zum kompilieren benutzt wird. Das Problem bei mir war das die Pakete kernel-headers und kernel-devel natürlich für meinen aktuellen Kernel installiert waren (war auch gewollt so), aber das build Skript immer im /lib/modules/alter_kernel_name gesucht hat.
    Ein

    Code
    uname -r

    hat den aktuellen Kernelnamen zu Tage gefördert.


    Abhilfe hat nur ein löschen des alten Kernels und anschließendem neuanlegen des Repository Klons.


    Habt Ihr eine Idee woran das liegt?

    Das cxd2099 Modul passt nicht zu ddbridge. Wahrscheinlich wurde das alte cxd2099 des Kernels mit dem neuen ddbridge aus dem Treiberpaket geladen..




    Kontrollieren, ob in einem Unterverzeichnis von /lib/modules/ ein weiteres - altes - cxd2099.ko herumliegt. Dieses z.B. in cxd2099.ko.old umbenennen.


    Danke UFO das war der richtige Tipp. Habe zwar im VDR Wiki schon soetwas als Fehlerquelle gesehen, allerdings habe ich da in den falschen Ordnern gesucht!


    Danke für die Hilfe die Karte wird jetzt erkannt und sauber mit zwei adapterX und je das nötige Frontend angezeigt.





    Nun da ich zur Zeit auf verschiedenen Plattformen teste stoße ich bei Fedora wieder an die grenzen der ganzen Kompilierung:
    ich hab installiert min.
    - gcc
    - make
    - patch
    - mercurial
    - kernel-headers
    - git
    - digest-perl-sha1
    - libncurses
    - libncurses-dev
    hmm mir fällt grad auch in Einklang mit dem benötigten und allem was ich mir erarbeitet hab net mehr ein. Aber beim kompilieren krachts bei

    Code
    make untar


    immer hier:



    Edit:



    Falls jemand unter Fedora 15 das Problem hat, dann muss patch downgedgradet werden und zwar auf eine Version 2.6.1-5. Welche eigentlich im 14'er aktuell war. Deshalb dann mit dem Befehl

    Code
    yum --releasever=14 --disablerepo='*' --enablerepo=updates --enablerepo=fedora --nogpgcheck downgrade patch


    downgraden. Bei mir war das zweimal nötig!


    Danke für die Hilfe, hat jetzt endlich soweit alles geklappt, vorher hatt ich eben das smp_lock Problem wegen dem 2.6.39'er Kernel nachdem ich jetzt nur speziell die Treiber für meine DD Cine S2 V6 kompiliert habe, wird auch dass ddbridge kernel modul geladen. Allerdings taucht die Karte immer noch nicht unter /dev/dvb
    und natürlich bin ich jetzt ein wenig ratlos wenn ich mir per dmesg die Meldungen vom Kernel beim laden anschaue werd ich nicht richtig schlau:


    und ein modprobe ddbridge bringt diesen fehler:

    Code
    FATAL: Error inserting ddbridge (/lib/modules/2.6.39-997-generic/kernel/drivers/media/dvb/ddbridge/ddbridge.ko): Operation not permitted


    wobei ich gar nicht weiß ob das nicht richtig so ist. Ich habe lediglich gesehen dass dieses Modul vom Kernel für meine Karte geladen wird ...


    Weiß jemand weiter?

    was müsste ich denn bei menuconfig alles einstellen um absolute minimal installation zu bekommen. Ich bin eigentlich nur an den Treibern für meine DigitalDevices Cine S2 V6 interessiert und natürlich werde ich vdr benötigen um dieses später als backend für mein xbmc zu haben. Nur bin ich mit diesen millionen Einstellmöglichkeiten leicht überfordert und weiß nicht was ich weglassen kann und was nicht.


    Vielleicht kann mir dazu ja jemand kompetente Auskünfte geben?