softhddevice-drm - "cma_alloc failed" - VDR verbraucht Speicher beim Verschieben von Schnittmarken

    Ich starte hier mal ein neues Thema, da der VDR beim Verschieben von Schnittmarken immer mehr Speichers verbraucht und dieser nicht mehr freigegeben wird, wodurch es dann auf den ARM Kistchen zu Problemen kommt. Je nach verwendetem Skin geht das mehr oder weniger schnell und ist mit allen Skins reproduzierbar.


    Beim Schneiden bemerkt man den Fehler noch nicht, er tritt erst auf wenn man die Aufnahme per Rückwärtstaste verlässt und wieder zum live TV zurückkehrt. Das Livebild hat dann Artefakte und zuckt vor sich hin bis man den Sender wechselt. Die Fehlermeldungen lauten während dem Schneiden: cma: cma_alloc failed, req-size: 138 Page, ret: -12

    Ein Erhöhen des cma Speichers auf 512MB brachte keine Besserung.


    Sobald eine Schnittmarke in einer Aufnahme verschoben wird, gönnt der VDR sich je nach skin ca. 30MB bis dann der CMA Speicher aufgebraucht ist.


    Sobald der VDR neu gestartet wird, wird der verbrauchte Speicher wieder freigegeben und das Spiel beginnt von neuem.


    Im Hauptthread von softhddevice-drm in Post #390 schreibt zillerbaer, was er vermutet, wie das Problem entsteht.

    Zitat von zillerbaer

    Es stellt sich mir so dar das vdr Videodaten im Arbeitsspeicher ablegt. Während des Verschiebens der Marken werden nur Stillpicture angezeigt. Dafür braucht softhddevice-drm nur einen Videobuffer. Der restliche Videobuffer ist freigegeben und wird jetzt Stückweise von vdr benutzt. Wird das Video dann gestartet braucht der Decoder 10 Videobuffer und der Deinterlacer 6 Videobuffer. Der Speicher steht jetzt aber nicht mehr zur Verfügung. Ich sehe nur einen Weg das zu beheben. Vdr darf nicht so viel Speicher benutzen so das er von softhddevice-drm genutzt werden kann.

    Ohne das am VDR etwas geändert wird, scheint das Problem hier nicht lösbar zu sein, deshalb meine Bitte an Klaus sich das ganze mal anzuschauen. Evtl. ist es möglich den Speicher nach dem Verschieben der Schnittmarken eines Films wieder freizugeben.


    kls könntest Du Dir die Sache bitte einmal ansehen?


    Viele Grüße

    Ich denke, das müsste gehen. Aber worin liegt der Unterschied zur CMA-Reservierung über die Kernelconfig oder einen Kernelparameter? Der Speicher wird ja auch weniger, wenn man ihn über den device tree reserviert? Oder habe ich einen Denkfehler?


    EDIT: CMA wird ja vom Decoder für die frames, von drm für die framebuffer und ggfs. für GLES genutzt falls aktiviert. Also von allem, was mit Bilddaten zu tun hat, damit zerocopy möglich ist. Irgendwas gibt da diesen Speicher nicht mehr frei. Was mich stutzig macht ist, dass es wohl mit dem Skin zu tun hat?! Ich sehe das Problem eher bei VDR oder dem Ausgabedevice.

    Wie verhalten sich denn hier die Desktops, auch wenn sie keinen CMA nutzen?

    Einmal editiert, zuletzt von rell ()

    Ist es nicht so, dass dem “normalen“ Arbeitsspeicher der CMA/DMA Bereich, den man im Kernel reserviert, nicht zur Verfügung steht? Oder der zumindest vorrangig für CMA genutzt wird?

    Ich verstehe es so:

    1GB gesamt

    256 MB CMA (und nur CMA)

    Bleiben 768MB für den per CPU angeforderten Speicher.


    Auch wenn ich falsch liege, wird der Speicher doch dann trotzdem ausgehen?!

    Die Hauptfrage wäre für mich: “Was passiert im VDR, wenn eine Schnittmarke verschoben wird?“ Wenn das mit den Stillpictures stimmt, werden die irgendwo nicht mehr freigegeben, oder?

    JoeBar Ich versuche grade das zu reproduzieren, kann aber nur per ssh zugreifen.

    Muss der Schnitt angestossen sein, damit das Problem auftritt, oder reicht es, Schnittmarken zu setzen, zu verschieben und aus der Aufnahme zurückzukehren?

    Ich habe hier zwar Probleme, dass der VDR nach dem Schließen der Aufnahme nicht mehr auf Tasteneingaben reagiert, aber den CMA Speicher ausgehen zu lassen, habe ich noch nicht geschafft. Allerdings läuft hier auch kein Schnitt.


    Gruß

    Andreas

    Es müssen nur die Marken verschoben werden, ggf. von zwei Filmen. Das ganze kannst du per top beobachten. Der Schnitt muss nicht gestartet sein.

    Ok, jetzt hab ichs auch hinbekommen, dass der CMA Speicher ausgeht...

    Wie kannst du mit top den CMA Speicher beobachten?


    Gruß

    Andreas

    Noch eine Frage, das passiert mit allen Skins, also auch mit lcars? Und wir reden von zillerbaers softhddevice, oder?

    Ja das geht mit allen Skins, mit top seh ich den gesamten Speicher denke ich, oder? Also top zeigt mir auf jeden Fall 3GB vom Pine an und wenn der VDR beendet ist, sind ca 500MB belegt. Sobald ich dann Schnittmarken verschiebe und 1GB überschritten wird fangen bei mir die CMA Fehlermeldungen an.

    Wenn ich richtig liege, wird der CMA auf dem H6 dynamisch “weggezwickt“.

    Code
    watch -n 0.1 cat /proc/meminfo

    So mache ich das. Da sehe ich direkt was weniger wird. Schau mal, ob das weiterhilft, denn evtl. wird soviel “normaler“ Speicher belegt, dass für den CMA nicht mehr genug übrig bleibt. Das Speichermanagment unterscheidet sich evtl. auf H3 und H6.

    Wenn tatsächlich der CMA weniger wird, können es nur Video/Decoderdaten sein.

    Ich konnte heute den CMA ausgehen lassen, allerdings musste ich da schon einige mehr Marken verschieben und Aufnahmen beenden. Und ich habe 1GB insgesamt - auf meinem H3. Ich kann das auch nochmal auf dem H6 testen.

    Ok, ich schau morgen mal.

    Ich glaube, dass man gar keine Marken verschieben muss um es zu reproduzieren. Es reicht zu pausieren und eine Marke anzuspringen. Wenn ich die Aufnahme verlasse flackert in den Videoframes des Streams (vermutlich) das Standbild aus der Aufnahme mit, als läge es noch in einem Buffer, der zwischen den anderen Frames immer wieder angezeigt wird. Es wirkt so, als wäre jedes 10. angezeigte Bild dieses Standbild. Wenn ich den Kanal wechsle, passt es wieder.


    Wenn das Standbild niemand mehr freigibt und es irgendwie in den Buffers verbleibt, erklärt das womöglich auch, dass der CMA Speicher weniger wird. Hab noch nicht in den Code geschaut, aber initiert der Kanalwechsel evtl. dass die buffer geleert werden, das Standbild aber geleakt wird? Muss mir den Code mal ansehen...

    Quasi zur Dokumentation habe ich hier ein Log gemacht und dazu geschrieben, was wann passiert. Basis ist mein gles Branch, aber das sollte keinen Unterschied machen.

    Vielleicht hilft es uns weiter.

    Hat hier schon jemand "weitergedacht"? Ansonsten mache ich das.

    JoeBar Kannst du mir nochmal sagen, wie du das am schnellsten reproduzieren kannst? Ich habe das bisher erst einmal geschafft und da musste ich sehr viele Marken verschieben bzw. anspringen und Aufnahmen starten/beenden.

    Funktioniert es bei dir auch, wenn du die Aufnahme startest, mit 7/9 eine Marke anspringst und die Aufnahme wieder verlässt, oder musst du zwingend Marken verschieben?

    Kannst du auch mit

    Code
    watch -n 0.1 cat /proc/meminfo

    beobachten, welcher Speicher weniger wird? Und am besten, du nutzt die letzte Version von zillerbaer und aktivierst nur softhddevice und skindesigner ;)

    Danke!


    Gruß

    Andreas

    Sorry Andreas, ich komm erst morgen dazu das mal mit der neuen Version zu testen. Ich meld mich morgen Abend versprochen ;)


    Viele Grüße

    Test mir L-Cars

    Nach einem weiteren Absturz

    Mir stürzt der VDR nach dem Verschieben der Schnittmarken immer mal wieder ab, keine Ahnung ob das was mit der PFNs busy Meldung was zu tun hat.

    Und jedes mal hab ich mehr freien CMA Speicher:/, sehr seltsam.

    Aber die cma: cma_alloc failed Meldungen blieben bisher mit zillerbaers neuester Version aus.

    Es ist normal, dass nach dem Absturz wieder mehr CMA als frei gemeldet wird, da er ja wieder freigegeben wird. Und so ganz verlassen darf man sich beim H6 auf diese CMA Anzeige nicht, weil m.E. noch CMA geholt werden kann, auch wenn CMAFree gegen 0 geht.


    3GB und 512MB CMA müssen vollkommen reichen! Das darf nicht zu wenig sein.


    Die erste Frage ist, warum VDR abstürzt. Dafür brauchts fast Logs oder einen bt. Und wenn das geklärt ist, ob/wo der Speicher verloren geht. Und welcher.


    Dafür nutzt die Momentaufnahme nach einem Crash nichts, da die Werte schon wieder zurückgesetzt wurden. Man muss tatsächlich in realtime beobachten wann was weniger wird.


    Ich kanns hier bisher nicht reproduzieren. Allerdings habe ich einen H3. Aber auch nur mit 1GB und 256MB für CMA. Habe heute mit markad mal alle Aufnahmen markiert und passe grad die Marken an. Nach drei Aufnahmen sehe ich bisher keine Probleme. Nutze aber auch meinen aktuellen gles branch, evtl. liegts auch daran.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden