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

JoeBar · April 4, 2021 at 8:26 PM

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.

Quote from 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

zillerbaer · April 13, 2021 at 6:46 PM

Vielleicht habe ich eine Möglichkeit gefunden das der Speicher für Decoder und Deinterlacer reserviert wird. Hier ist es beschrieben: https://www.kernel.org/doc/Documentat…rved-memory.txt

Hat jemand damit schon gearbeitet und weiss ob Decoder und Deinterlacer mit dem Eintrag im DTS mit dem reservierten CMA Speicher arbeitet oder ob der Treiber dazu noch angepasst werden muss?

rell · April 13, 2021 at 7:36 PM

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?

zillerbaer · April 13, 2021 at 7:55 PM

https://www.kernel.org/doc/Doc…emory/reserved-memory.txt:

Code

The operating system shall exclude reserved memory from normal usage

rell · April 13, 2021 at 8:05 PM

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?!

rell · April 13, 2021 at 8:09 PM

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?

rell · April 14, 2021 at 1:04 PM

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

JoeBar · April 14, 2021 at 5:32 PM

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.

rell · April 14, 2021 at 5:40 PM

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

Wie kannst du mit top den CMA Speicher beobachten?

Gruß

Andreas

rell · April 14, 2021 at 6:00 PM

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

JoeBar · April 14, 2021 at 10:30 PM

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.

rell · April 14, 2021 at 10:41 PM

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.

JoeBar · April 14, 2021 at 10:45 PM

Ok, ich schau morgen mal.

rell · April 14, 2021 at 10:56 PM

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...

rell · April 15, 2021 at 8:57 AM

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.

rell · April 26, 2021 at 12:18 PM

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

JoeBar · April 26, 2021 at 9:50 PM

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

Viele Grüße

rell · April 26, 2021 at 10:27 PM

Kein Stress!

JoeBar · April 27, 2021 at 8:54 PM

Test mir L-Cars

VDR neu gestartet

Alle 0,1s: cat /proc/meminfo PineH64: Tue Apr 27 20:21:15 2021

MemTotal: 2996504 kB

MemFree: 331328 kB

MemAvailable: 2420852 kB

Buffers: 83740 kB

Cached: 2004580 kB

SwapCached: 4 kB

Active: 319564 kB

Inactive: 2045348 kB

Active(anon): 744 kB

Inactive(anon): 276660 kB

Active(file): 318820 kB

Inactive(file): 1768688 kB

Unevictable: 0 kB

Mlocked: 0 kB

SwapTotal: 3145724 kB

SwapFree: 3145468 kB

Dirty: 196 kB

Writeback: 0 kB

AnonPages: 272788 kB

Mapped: 74400 kB

Shmem: 816 kB

KReclaimable: 198352 kB

Slab: 235860 kB

SReclaimable: 198352 kB

SUnreclaim: 37508 kB

KernelStack: 3056 kB

PageTables: 4020 kB

NFS_Unstable: 0 kB

Bounce: 0 kB

WritebackTmp: 0 kB

CommitLimit: 4643976 kB

Committed_AS: 892584 kB

VmallocTotal: 135290159040 kB

VmallocUsed: 6888 kB

VmallocChunk: 0 kB

Percpu: 1888 kB

HardwareCorrupted: 0 kB

AnonHugePages: 110592 kB

ShmemHugePages: 0 kB

ShmemPmdMapped: 0 kB

FileHugePages: 0 kB

FilePmdMapped: 0 kB

CmaTotal: 524288 kB

CmaFree: 66932 kB

Aufnahme gestartet, noch keine Schnittmarke verschoben

Alle 0,1s: cat /proc/meminfo PineH64: Tue Apr 27 20:22:36 2021

MemTotal: 2996504 kB

MemFree: 261168 kB

MemAvailable: 2340824 kB

Buffers: 82968 kB

Cached: 1995740 kB

SwapCached: 4 kB

Active: 320300 kB

Inactive: 2056612 kB

Active(anon): 744 kB

Inactive(anon): 298288 kB

Active(file): 319556 kB

Inactive(file): 1758324 kB

Unevictable: 0 kB

Mlocked: 0 kB

SwapTotal: 3145724 kB

SwapFree: 3145468 kB

Dirty: 336 kB

Writeback: 0 kB

AnonPages: 294288 kB

Mapped: 75936 kB

Shmem: 816 kB

KReclaimable: 198112 kB

Slab: 235516 kB

SReclaimable: 198112 kB

SUnreclaim: 37404 kB

KernelStack: 3136 kB

PageTables: 4100 kB

NFS_Unstable: 0 kB

Bounce: 0 kB

WritebackTmp: 0 kB

CommitLimit: 4643976 kB

Committed_AS: 906292 kB

VmallocTotal: 135290159040 kB

VmallocUsed: 6968 kB

VmallocChunk: 0 kB

Percpu: 1888 kB

HardwareCorrupted: 0 kB

AnonHugePages: 118784 kB

ShmemHugePages: 0 kB

ShmemPmdMapped: 0 kB

FileHugePages: 0 kB

FilePmdMapped: 0 kB

CmaTotal: 524288 kB

CmaFree: 41076 kB

Nach einem VDR Crash ?

Alle 0,1s: cat /proc/meminfo PineH64: Tue Apr 27 20:40:16 2021

MemTotal: 2996504 kB

MemFree: 616728 kB

MemAvailable: 2175916 kB

Buffers: 75476 kB

Cached: 1469592 kB

SwapCached: 60 kB

Active: 312916 kB

Inactive: 1635032 kB

Active(anon): 484 kB

Inactive(anon): 402824 kB

Active(file): 312432 kB

Inactive(file): 1232208 kB

Unevictable: 0 kB

Mlocked: 0 kB

SwapTotal: 3145724 kB

SwapFree: 3144444 kB

Dirty: 184 kB

Writeback: 0 kB

AnonPages: 402072 kB

Mapped: 75728 kB

Shmem: 432 kB

KReclaimable: 202692 kB

Slab: 242792 kB

SReclaimable: 202692 kB

SUnreclaim: 40100 kB

KernelStack: 3232 kB

PageTables: 4464 kB

NFS_Unstable: 0 kB

Bounce: 0 kB

WritebackTmp: 0 kB

CommitLimit: 4643976 kB

Committed_AS: 994664 kB

VmallocTotal: 135290159040 kB

VmallocUsed: 7048 kB

VmallocChunk: 0 kB

Percpu: 1888 kB

HardwareCorrupted: 0 kB

AnonHugePages: 229376 kB

ShmemHugePages: 0 kB

ShmemPmdMapped: 0 kB

FileHugePages: 0 kB

FilePmdMapped: 0 kB

CmaTotal: 524288 kB

CmaFree: 197996 kB

Nach einem weiteren Absturz

Display Spoiler

Alle 0,1s: cat /proc/meminfo PineH64: Tue Apr 27 20:49:37 2021

MemTotal: 2996504 kB

MemFree: 866452 kB

MemAvailable: 2389676 kB

Buffers: 76000 kB

Cached: 1449344 kB

SwapCached: 84 kB

Active: 299760 kB

Inactive: 1542980 kB

Active(anon): 512 kB

Inactive(anon): 317320 kB

Active(file): 299248 kB

Inactive(file): 1225660 kB

Unevictable: 0 kB

Mlocked: 0 kB

SwapTotal: 3145724 kB

SwapFree: 3144444 kB

Dirty: 0 kB

Writeback: 0 kB

AnonPages: 315380 kB

Mapped: 76248 kB

Shmem: 440 kB

KReclaimable: 186460 kB

Slab: 224376 kB

SReclaimable: 186460 kB

SUnreclaim: 37916 kB

KernelStack: 3088 kB

PageTables: 4128 kB

NFS_Unstable: 0 kB

Bounce: 0 kB

WritebackTmp: 0 kB

CommitLimit: 4643976 kB

Committed_AS: 895140 kB

VmallocTotal: 135290159040 kB

VmallocUsed: 6920 kB

VmallocChunk: 0 kB

Percpu: 1888 kB

HardwareCorrupted: 0 kB

AnonHugePages: 157696 kB

ShmemHugePages: 0 kB

ShmemPmdMapped: 0 kB

FileHugePages: 0 kB

FilePmdMapped: 0 kB

CmaTotal: 524288 kB

CmaFree: 367048 kB

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.

Display Spoiler

Apr 27 20:47:38 PineH64 vdr: [21938] [softhddev]SetPlayMode: 1

Apr 27 20:47:38 PineH64 vdr: [42913] dvbplayer thread started (pid=21938, tid=42913, prio=high)

Apr 27 20:47:38 PineH64 vdr: [42914] non blocking file reader thread started (pid=21938, tid=42914, prio=high)

Apr 27 20:47:38 PineH64 kernel: [ 3056.215026] alloc_contig_range: 68 callbacks suppressed

Apr 27 20:47:38 PineH64 kernel: [ 3056.215037] alloc_contig_range: [f2000, f2034) PFNs busy

Apr 27 20:47:38 PineH64 kernel: [ 3056.215221] alloc_contig_range: [f2040, f2074) PFNs busy

Apr 27 20:47:38 PineH64 kernel: [ 3056.215398] alloc_contig_range: [f2080, f20b4) PFNs busy

Apr 27 20:47:38 PineH64 kernel: [ 3056.215575] alloc_contig_range: [f20c0, f20f4) PFNs busy

Apr 27 20:47:38 PineH64 kernel: [ 3056.215863] alloc_contig_range: [f2100, f2134) PFNs busy

Apr 27 20:47:38 PineH64 kernel: [ 3056.216042] alloc_contig_range: [f2140, f2174) PFNs busy

Apr 27 20:47:38 PineH64 kernel: [ 3056.216302] alloc_contig_range: [f2180, f21b4) PFNs busy

Apr 27 20:47:38 PineH64 kernel: [ 3056.216502] alloc_contig_range: [f21c0, f21f4) PFNs busy

Apr 27 20:47:38 PineH64 kernel: [ 3056.218209] alloc_contig_range: [f2000, f2060) PFNs busy

Apr 27 20:47:38 PineH64 kernel: [ 3056.218448] alloc_contig_range: [f2080, f20e0) PFNs busy

Apr 27 20:47:44 PineH64 vdr: [21938] [softhddev]Clear:

Apr 27 20:47:44 PineH64 vdr: [21938] [softhddev]StillPicture: pes 0xaaaade8ed9b0 43640

Apr 27 20:47:44 PineH64 systemd[1]: vdr.service: Main process exited, code=killed, status=11/SEGV

Apr 27 20:47:44 PineH64 systemd[1]: vdr.service: Failed with result 'signal'.

Apr 27 20:47:44 PineH64 systemd[1]: vdr.service: Scheduled restart job, restart counter is at 2.

Apr 27 20:47:44 PineH64 systemd[1]: Stopped Video Disk Recorder.

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.

rell · April 27, 2021 at 9:09 PM

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.

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

Participate now!

Tags