Beiträge von wmautner

    Ich benütze zur Zeit (siehe Signatur) einen 4.14er, aber noch die Version VOR dem Meltdown-Patch, da mit diesem (und auch einem 4.13er aus dem Kernel-ppa mit den Patches) meine TT-S2-3200 oopst.

    Der 4.14 hat zudem den Vorteil, daß er alle cine-S2/C/T Treiber bereits beinhaltet und zusätzlich den für TT-S2-3200, also kein dkms dafür mehr nötig ist.

    Aber auf meinem (ebenfalls noch truxty) Desktop-System (wegen KDE4 nicht direkt upzugraden) und dem xubuntu-System am Arbeitsplatz läuft

    z.Z. 4.13.0-31.34~16.04.1

    Versionstabelle:

    4.13.0-31.34~16.04.1 0

    500 http://ppa.launchpad.net/canonical-kernel-team/ppa/ubuntu/ xenial/main amd64 Packages


    aus obigem ppa, welches auch regelmäßig upgedated wird und auch schon die Meltdown- und Spectre-Patches enthält.

    Hab auch schon den 4.14er drauf - genauer gesagt, den 4.14.10-041410-generic.

    Der hat noch nicht den Meltdown-Patch, denn der 4.14.11 mit ebendiesem oopst mit der TT S2-3200 ...

    Jedenfalls brauche ich keine dkms-Pakete mehr außer dem für nvidia. Nvidia (387) meckert wegen einer Library,

    die aber problemlos nachinstalliert werden kann, und baut dann.

    # lspci -vv|grep -i dvb

    03:00.0 Multimedia controller: Digital Devices GmbH Octopus DVB Adapter

    Subsystem: Digital Devices GmbH Cine S2 V6 DVB adapter

    Kernel driver in use: budget_ci dvb

    root@hdvdr:~# dmesg|grep DDB

    [ 8.740220] dvbdev: DVB: registering new adapter (DDBridge)

    [ 8.740221] dvbdev: DVB: registering new adapter (DDBridge)

    [ 9.905628] i2c i2c-1: Found ST STV0367 DDB DVB-C/T with ChipID 60 at adr 1F

    [ 10.409456] ddbridge 0000:03:00.0: DVB: registering adapter 1 frontend 0 (ST STV0367 DDB DVB-C/T)...

    [ 10.410656] i2c i2c-1: Found ST STV0367 DDB DVB-C/T with ChipID 60 at adr 1E

    [ 10.702074] ddbridge 0000:03:00.0: DVB: registering adapter 1 frontend 0 (ST STV0367 DDB DVB-C/T)...


    Ist aber schon eine ziemlich alte Octopus :)

    Danke :)

    Ja, mit 4.4 plus experimental-dkms und auch 4.10 (da aber mit Jasminis dkms-Paketen) lief die. Allerdings hab ich den Rechner bereits nach Wechsel auf 4.10 gewechselt und der kann leider kein Resume aus S5 mehr, nur noch S3 - und dann ist mir das Problem mit dem stb0899 aufgefallen, daß das nämlich nach dem Resume nicht mehr mag. Schon mit dem dkms, und natürlich auch mit den im 4.14 integrierten Modulen.

    Z.Z. pfeife ich auf den Meltdown und benütze 4.14.10 noch ohne der "Härtung".

    Lieber SurfaceCleaner,

    dynamite kann das Frontend zwar "idle" setzen, aber ent- oder neuladen der Module tut es natürlich auch nicht :)

    Was meinst Du mit "etwas lahm geladen"?

    Hab gerade versucht, die Module bei bereits laufendem VDR "nachzuladen" (vorher blacklisted) und konnte den OOPS hier

    produzieren, also wieder beim Attachen der Tuner (wobei stb0899 bereits mit lsmod als geladen angezeigt war).


    Irgendwann werde ich mir doch eine andere Single- oder Dual-SAT-Karte dazu nehmen, oder weniger aufnehmen :)

    Die FB ... da findet sich auch meine Bessere Hälfte schon mit dem Handy und vdrmanager ab.


    Liebe Grüße aus Wien!

    Danke :)

    Ja, klar. Wollte nur möglichst ein einheitliches "Umfeld" - und der Hauptgrund für 4.14 ist ja beim VDR hier die eingebauten Module für Octopus _und_ tt3200.

    Wobei ich allerdings durch Blacklisten des stb0899-Moduls den Oops wegkriege. Die Fernbedienung (am saa7164) funktioniert noch, aber eben ein Tuner weniger ...

    Der stb0899-Treiber war mir ohnehin etwas suspekt, da der nach S2Ram nicht mehr wollte - hatte da eine Hoffnung, daß dieses mit dem in-Tree-Modul sich bessern könnte, naja. Die 3200 ist auch schon ziemlich alt und wird nicht mehr produziert.


    Liebe Grüße aus Wien und danke für die unermüdliche Entwicklung :)

    Oh danke ... ja, mal sehen ob ich da einen Bugreport zustandekriege.

    Den 4.14 wollte ich ja erst, weil der die Octopus-Treiber im Kernel hat und auch die gute alte S-3200. Dann kam der Meltdown und ich wollte den gepatchten. Auf anderen Rechnern funktioniert er auch problemlos, cat /proc/cpuinfo meldet brav den "bug: cpu_insecure" (erst bei 4.14.11) ... nur mit meinen DVB-Treibern, vermutlich auch dem zickigen stb0899, der schon nach "supend to ram" streikte, mag er nicht.

    Nun, ich werde noch versuchen, den stb0899 vorerst zu blacklisten und erst zuletzt zu laden, oder mit den Kernel-Parametern spielen.

    Immerhin läuft der 4.14-10 gut.

    Liebe Leute,


    Warnung:

    der Kernel 4.14.0-041400 aus dem Mainline-PPA tut anstandslos mit meinem VDR.

    Wohingegen der - gegen Meltdown "gehärtete" 4.14.11-041411 - beim Laden der dvb-Treiber

    sich mit einem OOPS meldet und ich habe dann keine Frontends:

    Die Original-(.dpkg-dist) sieht bei mir etwa so aus:

    %Season%=system(vdrseriestimer,--title %Title% --subtitle %Subtitle% --date %date% --time %time% --channel %chnr% --timet %time_lng% )

    %DateVar%=%time_w% %date% %time%

    %SerieSD%=%Subtitle% ? %Subtitle% : %DateVar%

    %SerieVar1%=Serie~%Title%~%SerieSD%

    %Serie%=%Season% ? %Season% : %SerieVar1%

    --

    Ich verwende epgd, daher kein seriestimer mehr nötig, meine epgsearchuservars.conf beginnt so:

    %SPATH%=Serien~%TITLE%

    %MPATH%=Filme~%TITLE%

    %SeasonEpisode%=%SPATH%~S%Staffel%E%Staffelfolge% - %Subtitle%

    ....

    Die Lösung für Faule wäre allerdings die, "Series" in "Serie" umzubenennen und einen Symlink mit dem Namen "Series", der darauf zeigt, zu erstellen :)

    Wenn das chroot keine ssh-Verbindung akzeptiert, mußt Du im chroot-System den sshd wohl erst starten (und im "Muttersystem" vorher den Port freimachen).

    Wenn Du im chroot bist, muß im Pfad /lib/modules/`uname -r`/kernel/drivers/net/ethernet/realtek das Modul r8169.ko zu finden sein.

    Es muß allerdings im Muttersystem aktiv gewesen sein, und die IP-Adresseinstellungen sind dann auch identisch.

    Die zu /run... verlinkte resolv.conf kannst Du "unlink"en und eine manuelle erstellen im chroot, mit manuellem Nameserver-Eintrag.

    Nun, wenn die (ifconfig p4p1) numerische IP der Netzwerkkarte ok und im DHCP-Bereich (DHCP und DNS-forwarding macht wohl der Router?) liegt,

    solltest ja mit ssh/putty <IP-des-vdr> schon mal remote auch draufkommen? Dann könntest auch das Problem mit den Tastorturen usw. leichter debuggen.

    Kann es sein, daß der Router einen ungültigen oder nur IPV6-DNS-Server eingetragen hat und die anderen Rechner "händisch" konfiguriert wurden?