Hat jemand softhddevice mit nouveau am Laufen?

  • Inzwischen ist bei Ubuntu 18.04 der 5er Kernel standardmäßig installierbar. Leider musste ich feststellen, dass das Modul für den nvidia-340 Treiber nicht mehr mit DKMS kompiliert. Ich hoffe nur, dass die 340er Version im 5er doch noch mal laufen wird - die GF 9300 ist für TV ja sonst völlig ausreichend.


    Aufgrund des Problems habe ich mir den nouveau Treiber mal wieder angesehen und er bietet inzwischen VDPAU-Unterstützung - auch für meine Graka. Testweise habe ich den mal installiert. vdpauinfo liefert auch korrekte Ausgaben:

    Leider stürzt der VDR jedoch mit softhddevice beim Starten ab oder startet immer wieder neu (Log: vdr[1397]: vdr: ../src/gallium/drivers/nouveau/nouveau_vp3_video_vp.c:368: nouveau_vp3_fill_picparm_h264_vp: Zusicherung »dec->refs[refs[j]->valid_ref].vidbuf == refs[j]« nicht erfüllt.)


    Das OSD (Kanalinfo) blendet beim Start ein, aber das TV Bild bleibt schwarz. Eine andere softhddevice Version lies den VDR mit der Kanalinfo einfrieren.


    Hat jemand ggf. softhddevice mit nouveau am Laufen?

    My VDRs:

  • Hast du mal das Paket für nvidia-340 aus https://launchpad.net/~graphic…ield.series_filter=bionic probiert? Das scheint Patches für den Kernel 5.0 und 5.1 zu haben.


    Ansonsten kannst du auch beim Kernel von Ubuntu 18.04.1 bleiben - dann hast du einen LTS-Kernel, mit dem du bis 2023 kommst, bis dahin ist der nvidia-340 Treiber längst ofiziell obsolet.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Danke für den Tipp - das kann ich mal probieren.

    So richtig toll scheint der nvidia-Treiber aber auch nicht mehr zu funktionieren - daher die Idee mit nouveau.

    Mit Kernel 4.18.0-25 gibts immer folgende Warnung/Fehler beim Start (dmesg):

    Auch beim Entladen der DVB-Module macht der m.E. Probleme.


    Rückmeldungen, falls jemand nouveau mit VDPAU und dem VDR zum Laufen gebracht hat, können gerne noch gepostet werden...

    My VDRs:

  • Hier die Rückmeldung:


    mit dem Treiber aus dem o.g. PPA klappt es nun auch mit Kernel 5.0. Auch reduzieren sich die Meldungen unter Kernel 4.18 auf wenige Zeilen - analog ist es im 5.0er:

    Code
    1. [ 5.715725] ACPI Warning: \_SB.PCI0.IXVE.IGPU._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20181213/nsarguments-66)
    2. [ 5.770188] resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000dffff window]
    3. [ 5.770357] caller os_map_kernel_space+0x8d/0xb0 [nvidia] mapping multiple BARs

    Und nun muss ich dennoch auf Updates des Kernel warten, da man diese nervigen Debugmeldungen nicht rausgenommen hat:

    Code
    1. [ 36.626689] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 42000000...870000000, frontend: 0...0
    2. [ 40.499663] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 950000000...2150000000, frontend: 950000000...2150000000
    3. [ 52.958558] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 42000000...870000000, frontend: 0...0
    4. [ 55.182528] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 42000000...870000000, frontend: 0...0
    5. [ 55.775289] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 42000000...870000000, frontend: 0...0

    Bleibt dann nur wieder media_build, wo ich diese Debugmeldung (dvb_frontend.c) schon entfernt habe...

    Dies ist hier bereits thematisiert...

    My VDRs:

    The post was edited 1 time, last by dad401 ().

  • Und nun muss ich dennoch auf Updates des Kernel warten, da man diese nervigen Debugmeldungen nicht rausgenommen hat:

    Die kann man auch filtern - journald kann man sagen, dass man Kernel-Messages nur bis zu einem bestimmten Level haben möchte oder komplett ignorieren möchte: https://www.freedesktop.org/so….conf.html#MaxLevelStore=

    Code: /etc/systemd/journald.conf
    1. [Journal]
    2. MaxLevelKMsg=notice

    Und rsyslog (das die meisten klassischen Logdateien in /var/log/ verwaltet) kann anhand des Inhalts einer Nachricht Logmeldungen verwerfen, also z.B.:

    Code: /etc/rsyslog.d/10-ignore.conf
    1. :msg,contains,"dvb_frontend_get_frequency_limits" ~

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo,


    ich war jetzt erstmal im Urlaub und komme jetzt zum Testen.


    Leider wird dmesg weiter mit den Logmeldungen befüllt (Kernel 5.0.0-27-generic):

    Code
    1. [ 77.365679] i2c i2c-4: cx24117_load_firmware: FW version 1.44.95.2
    2. [ 77.365692] i2c i2c-4: cx24117_firmware_ondemand: Firmware upload complete
    3. [ 77.398019] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 0...0, frontend: 950000000...2150000000
    4. [ 77.433987] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 0...0, frontend: 950000000...2150000000
    5. [ 81.045862] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 0...0, frontend: 950000000...2150000000
    6. [ 131.628706] dvb_frontend: dvb_frontend_get_frequency_limits: frequency interval: tuner: 42000000...870000000, frontend: 0...0

    /etc/systemd/journald.conf enthält

    MaxLevelKMsg=notice


    wobei dies quasi schon default war. Und /etc/rsyslog.d/10-ignore.conf habe ich wie oben angelegt. Danach auch zu Sicherheit neugestartet.


    Ideen?

    My VDRs:

  • dad401


    Hatte ich vor einiger Zeit mit VDPAU @ nouveau befasst und glaub auch mal was geschrieben hier. Grundsätzlich hatte ich das ganze ans Laufen gebracht gehabt, nur fehlt der freien VDPAU Implementation leider der ganze heiße Scheiß zur Bildaufbereitung, temporal, temporal_spatial, etc. der VDPAU ausgezeichnet hat. Denke das hat auch Lizenz-rechtliche Gründe.


    D.h. selbst wenn Du es ans laufen bekommst, wird Bob als Deinterlacer das höchste der Gefühle sein, ganz zu Schweigen von anderen fehlenden Features wie z.B. HQ Scaling, Studio Levels, usw.

    HowTo: APT pinning

  • Ja ist bekannt - bis der Patch bei Ubuntu im Standardkernel ankommt dauert das aber ne Weile. Ziel war ohne eigenes Bauen der Module (media_build) auszukommen.


    Wie ich jedoch sehe, wird die Meldung nicht mehr in syslog / kern.log geloggt sondern lediglich nach /dev/kmesg, welches mit dmesg ausgegeben wird. D.h. die Ausgabe mit dmesg bleibt unschön, aber zumindest werden die Meldungen nicht mehr in die Logdateien geschrieben.

    Bzgl. rsyslog: Kann es sein, dass anstelle ~ nun stop als Keyword genommen werden muss (Manpage rsyslog.conf bzw. hier)? Hab es mit beiden probiert - scheint mit beiden zu klappen (getestet mit kern.log)

    My VDRs:

  • Hatte ich vor einiger Zeit mit VDPAU @ nouveau befasst und glaub auch mal was geschrieben hier. Grundsätzlich hatte ich das ganze ans Laufen gebracht gehabt, nur fehlt der freien VDPAU Implementation leider der ganze heiße Scheiß zur Bildaufbereitung, temporal, temporal_spatial, etc. der VDPAU ausgezeichnet hat. Denke das hat auch Lizenz-rechtliche Gründe.

    Ich glaube das habe ich gelesen um es dann zu probieren. Demnach scheint es (derzeit) keinen Sinn zu machen.

    Fazit:

    Die alten VDRs (GeForce 9300M/8400?) müssen auf dem 340er bleiben und damit bei 18.04 LTS, mit Glück gibts den 340er noch in der nächsten LTS. Danach ist Ruhe, falls es der nouveau bis dahin nicht schafft. 2 meiner Haupt-VDR sind inzw. auf Intel umgestellt und laufen inzw. ganz gut (inkl. HVEC DVB-T2 Sender).

    My VDRs:

  • Hi,

    dann mit Verlust anderer Meldungen

    Code
    1. /etc/sysctl.conf
    2. #kernel.printk = 3 4 1 3

    Wirkt das auch auf den Ringpuffer /dev/kmsg und damit auf die dmesg Ausgabe? Ich dachte das wirkt nur auf die Consolen-Ausgabe. Es steht derzeit auf 4 4 1 7. "Current" ist damit 4 und dürfte (soweit ich verstanden) die Meldung mit 7 (dprintk) nicht ausgeben?! Tut sie ja aber...oder gilt die letzte Ziffer hier (boot-time-default)?


    EDIT: getestet mit 3 4 1 3 und dmesg gibt die Meldung weiterhin aus.


    Mein Workaround wäre erstmal der gewesen:

    Code
    1. alias dmesg='dmesg -l emerg,alert,crit,err,warn,notice,info'

    My VDRs: