Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Nachricht

s3n0 · #1

Hi.

When using a friend's Vu+ Uno 4K SE device, with OpenATV 7.5.1 installed, the RAM memory is slowly filling up - i.e. there is memory overloading.

At first, I observed the filling up, which was happening quickly. Within a few hours, about 7-15 hours, the RAM was completely filled up and the Enigma2 froze:

Later, with repeated tests, I don't know why, the RAM was gradually filling up only very slowly - in an interval of about 6-12 days:

So the problem is basically that the RAM is gradually being filled specifically by the "enigma2" process !

I didn't find anything special in the system stack (dmesg), except for this:

Code: Alles auswählen

Mar  5 06:21:57 vuuno4kse kern.warn kernel: [465661.043843] enigma2 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=-999
Mar  5 06:21:57 vuuno4kse kern.warn kernel: [465661.051820] CPU: 0 PID: 1905 Comm: enigma2 Tainted: P           O    4.1.20-1.9 #1
Mar  5 06:21:57 vuuno4kse kern.warn kernel: [465661.059484] Hardware name: Broadcom STB (Flattened Device Tree)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.065515] [<c0017b58>] (unwind_backtrace) from [<c0013634>] (show_stack+0x10/0x14)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.073360] [<c0013634>] (show_stack) from [<c067c730>] (dump_stack+0x7c/0x90)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.080684] [<c067c730>] (dump_stack) from [<c00a8c88>] (dump_header+0x7c/0x1a0)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.088178] [<c00a8c88>] (dump_header) from [<c00a93f8>] (oom_kill_process+0x2d8/0x498)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.096279] [<c00a93f8>] (oom_kill_process) from [<c00a97fc>] (__out_of_memory+0x244/0x390)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.104727] [<c00a97fc>] (__out_of_memory) from [<c00a9b90>] (out_of_memory+0x6c/0x74)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.112741] [<c00a9b90>] (out_of_memory) from [<c00adb40>] (__alloc_pages_nodemask+0x6ac/0x8a8)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.121536] [<c00adb40>] (__alloc_pages_nodemask) from [<c00a8110>] (filemap_fault+0x174/0x43c)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.130333] [<c00a8110>] (filemap_fault) from [<c00c6850>] (__do_fault+0x38/0x94)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.137913] [<c00c6850>] (__do_fault) from [<c00cad18>] (handle_mm_fault+0xd88/0x1160)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.145927] [<c00cad18>] (handle_mm_fault) from [<c001e8b8>] (do_page_fault+0x104/0x52c)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.154114] [<c001e8b8>] (do_page_fault) from [<c0009364>] (do_PrefetchAbort+0x30/0x90)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.162214] [<c0009364>] (do_PrefetchAbort) from [<c001459c>] (ret_from_exception+0x0/0x24)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.170659] Exception stack(0xcecdffb0 to 0xcecdfff8)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.175803] ffa0:                                     b033b4a0 afdd7b48 00000000 00000000
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.184075] ffc0: afdd7b48 00000001 b033b4a0 b033b4a0 b6545150 00000000 b5784870 b6545150
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.192347] ffe0: b6545b94 afdd7ae0 b62f45b4 b622fd9c 600d0010 ffffffff
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.199390] Mem-Info:
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.201788] active_anon:161495 inactive_anon:45 isolated_anon:0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.201788]  active_file:691 inactive_file:727 isolated_file:0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.201788]  unevictable:0 dirty:0 writeback:0 unstable:0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.201788]  slab_reclaimable:1084 slab_unreclaimable:2520
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.201788]  mapped:859 shmem:984 pagetables:1108 bounce:0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.201788]  free:2519 free_pcp:298 free_cma:0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.235115] DMA free:11008kB min:8192kB low:10240kB high:12288kB active_anon:268896kB inactive_anon:72kB active_file:1076kB inactive_file:1104kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:350208kB managed:
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.280024] lowmem_reserve[]: 0 0 390 390
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.284605] HighMem free:2084kB min:388kB low:2920kB high:5452kB active_anon:377084kB inactive_anon:108kB active_file:176kB inactive_file:484kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1714176kB managed:
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.328726] lowmem_reserve[]: 0 0 0 0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.332792] DMA: 813*4kB (UEM) 278*8kB (UEMR) 9*16kB (UR) 1*32kB (R) 0*64kB 0*128kB 3*256kB (R) 1*512kB (R) 0*1024kB 0*2048kB 1*4096kB (R) = 11028kB
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.346835] HighMem: 232*4kB (MRC) 47*8kB (MR) 16*16kB (R) 7*32kB (R) 1*64kB (R) 0*128kB 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2104kB
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.360252] 1797 total pagecache pages
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.364274] 0 pages in swap cache
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.367694] Swap cache stats: add 0, delete 0, find 0/0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.373031] Free swap  = 0kB
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.376025] Total swap = 0kB
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.379008] 516096 pages RAM
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.381988] 428544 pages HighMem/MovableOnly
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.386538] 330979 pages reserved
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.389960] 4096 pages cma reserved
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.393550] [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.402203] [  902]     0   902     1530      188       6       2        0         -1000 udevd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.411058] [ 1162]     0  1162      733       55       5       2        0             0 udhcpc
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.419876] [ 1281]     0  1281   134591       74     261       2        0             0 dvb_server
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.429175] [ 1283]     0  1283   129962       56     257       2        0             0 init_client
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.438437] [ 1390]     0  1390     2861       65       6       2        0             0 chronyd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.447497] [ 1394]     0  1394      677       49       4       2        0             0 S90checkinterne
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.457095] [ 1422]     0  1422      530       26       4       2        0             0 dropbear
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.466226] [ 1439]   996  1439      472       52       5       2        0             0 rpcbind
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.475131] [ 1441]   997  1441      565       48       4       2        0             0 dbus-daemon
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.484520] [ 1461]     0  1461      628      109       5       2        0             0 rpc.mountd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.493681] [ 1501]   995  1501      503       38       4       2        0             0 rpc.statd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.502793] [ 1517]     0  1517      733       22       4       2        0             0 inetd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.511565] [ 1521]     0  1521     1040       53       5       2        0             0 bluetoothd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.520876] [ 1526]     0  1526      733       24       5       2        0             0 syslogd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.529794] [ 1531]     0  1531      733       25       5       2        0             0 telnetd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.538825] [ 1536]     0  1536      431       14       4       2        0             0 socketdaemon
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.548170] [ 1541]     0  1541     1391       84       6       2        0             0 vsftpd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.557118] [ 1544]     0  1544      733       24       4       2        0             0 klogd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.565856] [ 1553]     0  1553      733       55       4       2        0             0 udhcpc
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.574810] [ 1559]     0  1559      684       68       3       2        0             0 crond
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.583545] [ 1564]     0  1564      791       70       4       2        0             0 enigma2.sh
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.592842] [ 1571]     0  1571      896       26       3       2        0             0 oscam
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.601577] [ 1575]   999  1575      687       92       4       2        0             0 avahi-daemon
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.611056] [ 1576]     0  1576     4214      502       7       2        0             0 oscam
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.619785] [ 1580]   999  1580      625       39       4       2        0             0 avahi-daemon
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.629233] [ 1581]     0  1581    11540     1718      23       2        0             0 zerotier-one
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.638580] [ 1590]     0  1590     7618      385      18       2        0             0 smbd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.647382] [ 1618]     0  1618     7261      372      17       2        0             0 smbd-notifyd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.656755] [ 1619]     0  1619     7262      372      17       2        0             0 smbd-cleanupd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.666202] [ 1647]     0  1647     9079       65      10       2        0             0 automount
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.675449] [ 1712]     0  1712   177571   155932     345       2        0          -999 enigma2
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.684362] [ 1716]     0  1716     1478       96       6       2        0             0 shellinaboxd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.693846] [ 1717]     0  1717     1478       96       6       2        0             0 shellinaboxd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.703191] [ 1861]     0  1861      452       27       4       2        0             0 wsdd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.711962] [ 1832]     0  1832     1582      155       7       2        0             0 wget
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.720602] [ 1862]     0  1862      733       24       4       2        0             0 run-parts
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.729799] [ 1887]     0  1887     1391       85       5       2        0             0 vsftpd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.738618] [ 1897]     0  1897     1399       90       5       2        0             0 vsftpd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.747554] [ 1900]     0  1900      530       22       4       2        0             0 dropbear
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.756540] [ 1902]     0  1902      677       24       5       2        0             0 50default
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.765724] [ 1908]     0  1908     1391       84       4       2        0             0 vsftpd
Mar  5 06:21:58 vuuno4kse kern.err kernel: [465661.774537] Out of memory: Kill process 1581 (zerotier-one) score 9 or sacrifice child
Mar  5 06:21:58 vuuno4kse kern.err kernel: [465661.782606] Killed process 1581 (zerotier-one) total-vm:46160kB, anon-rss:6872kB, file-rss:0kB
Mar  5 06:21:57 vuuno4kse daemon.info avahi-daemon[1575]: Interface ztmjfm6yzy.IPv6 no longer relevant for mDNS.
Mar  5 06:21:58 vuuno4kse daemon.info avahi-daemon[1575]: Leaving mDNS multicast group on interface ztmjfm6yzy.IPv6 with address ****::****:****:****:****.

Of course, after the error occurred and the set-top box froze, since it was unusable (it was not possible to connect to the set-top box via the network), I first had to switch the path to the stored dmesg LOG files from the temporary RAM disk ("volatile" disk) to the standard internal flash memory. This is so that after rebooting the set-top box the system stack (dmesg) records from the temporary RAM disk would not be lost.

I tried a small experiment - removing the ZeroTier plugin from the set-top box. However, the problem was not solved by removing ZeroTier. I think that the Linux system was simply trying to free up RAM according to the preset priorities to prevent the Linux system kernel from crashing. That is why OOM-Killer threw ZeroTier out of the system in order to free up more RAM.

I tried disabling IPv6 support in the set-top box to see if that would help... but that didn't help either.

This multi-tuner set-top box is also used as a restream station/server. However, we tested it both with and without restreaming. The restreaming had no effect on the problems.

So far, we have solved the problem for my friend by restarting the enigma2 process every night at 3:15 am (using CRON). Simply a silent restart of the GUI:

Code: Alles auswählen

#!/bin/bash

init 4; sleep 5; killall -9 enigma2 > /dev/null 2>&1
sync; echo 1 > /proc/sys/vm/drop_caches; sleep 1      # clearing system buffers / system caches
init 3; sleep 60
wget -qO- "http://127.0.0.1/api/powerstate?newstate=5" > /dev/null 2>&1
echo "$(date '+%Y-%m-%d %H:%M:%S')" > /tmp/e2-auto-restart-via-cron.log

Could someone write what to do about it ?

Thanks.

#2

Why don't you have a swap with 64-128MB activated? That is normaly mandantory for ANY newer image since oATV5.x.
Arrange that on an USB-Key formatted ext4, fixed mounted to /media/usb (the hdd has also fixed, but be mounted to /media/hdd.
This will help the memory manager to handle the implemented cache-flush operations, cyclic ongoing in a clean installation.
I always tell people "NO E2 without a local storage", and those who do so, may have less problems.
In many ARM 4K boxes this mandantory swap is already built in the sysem (in flash) without user intervention. BUT all mipsels, and some ARM 4K need user intervention.

s3n0 · #3

Hi... thanks for the reply.

So I have a Vu+ Zero 4K @ ATV 7.5.1 at home and there is no problem there. The "enigma2" process does not clog up the RAM. Even after running for several days, there is still a very low memory usage. Even there is very big available RAM, that's a fact.

And... slso with my Vu+ Solo SE V2 @ ATV 7.5.1 there is no problem with the RAM usage - for the "enigma2" process. Even though it is without the 4K chipset.

A friend used an external HDD. Maybe he only had it formatted to FAT32/NTFS. And not to Ext4. We wondered if this HDD was defective. So we tried pulling it out. But that didn't solve the problem. So do you recommend putting the HDD back into the set-top box, but with the fact that it must be formatted to Ext4 ?

The problem is the constant and gradual increase in RAM usage. In my opinion, the "enigma2" process should not behave like this. In my opinion, this is stupidity, that the RAM usage increased unexpectedly until the system crashed. Every approximately 2 hours, the RAM usage with the "enigma2" process increased by up to 10-20 MB - in the faster case. And in the slower case, it increased more slowly, but also regularly, and after approximately 7-12 days, "enigma2" again froze hard.

Thanks.

#4

Streaming causes immensely amont of memory operations between components via the internal bus structure invoking vtuners (net & stream).
I never get the swap touched in normal TV use of my boxes. But when I remote stream one channel to another box, or receive IPTV, I see the SWAP scratched just a little even after a short time, but not raising significantly over time. It seems just the presence of that alternative memory device out of the RAM makes the memory manager work propper. Remember, that a dedicated linux install also always has a swap activated.
See also:

Code: Alles auswählen

root@ZGemmaH7-1:~# uptime
 17:31:37 up 1 day, 21:25,  1 user,  load average: 0,00, 0,00, 0,00
root@ZGemmaH7-1:~# free
               total        used        free      shared  buff/cache   available
Mem:         1027804      924384       23888         632      114284      103420
Swap:         262140         136      262004

I JUst did a little stream test to see, I the softcam was working after fresh flash and restore of that oATV7.5.1 few days ago.

And again: That behavior is same since early oATV5.x unchanged til now.

By the way: I only use LAN, and NEVER WLan / WiFi.

s3n0 · #5

Hi.

A friend used ATV 6.4 before and these freezing problems did not exist in it. The same configuration and the same purpose of using the set-top box.

I already wrote above that we tested the operation of the set-top box without restreaming. And it did not help. So restreaming in this particular problem has no effect.

Now a friend wrote to me that there was an HDD with Ext4 already formatted. And the same problem I'm describing occurred in this case too :-(. I also advised him to try a USB flash drive instead of an HDD. Insert a USB flash drive and format it to Ext4 and reboot the set-top box. His HDD could also be damaged.

But... I would rather be interested in whether there is any possibility of extended debugging of the 'enigma2' process. I don't mean the Python code of the Enigma2 - standard output (e2 debug log), but debugging for the 'enigma2' process itself under Linux. Linux set-top boxes have very limited options when it comes to system tools. I mean whether it is possible to find out why the 'enigma2' process is using RAM or what exactly this process is holding for data.

BTW, since I'm mentioning e2 debug, I've already tried that too - using and reading the e2 debug file. But I didn't see anything special there. The e2 debug simply stopped writing (creating) the file - in the moment the set-top box freezes.

pololoko111 · #6

I have the same problem when I stream one channel to another decoder or receive IPTV.
SF8008 Supreme 7.5.1 and 7.6
To avoid enigma2 freezing problems I use the clearmem plugin.
From what I remember older versions of OpenAtv did not have this problem.

Bild

RickX · #7

I would check the RAM status on the command line using the "free" command.

The important value is not the "free" column, but the "available" column. Only if "available" goes down to zero this is a problem.

The "free" memory is only a small size which is reserved for quick start of processes. It is normal behaviour that "free" is very small, as all free RAM is used dynamically as I/O buffer.

Regarding problems and memory leaks, only the "available" figure is relevant.

s3n0 · #8

In my screenshots above you can see the "htop" tool. It shows everything you need (the legend / info for "htop" tool is displayed after pressing F1). There you can see several "types" of memory usage by the "enigma2" process in columns. The upper part of "htop" shows the overall memory usage (including system cache/system buffer).

#9

As long as SWAP is zero, the memory manager will not work propperly.
When did you test with an activated SWAP of about 128MB?
It does not matter, if you in former times something not had to do.
We are in the present, and things change sometimes.

s3n0 · #10

I've already written twice, but I'll write a third time... and maybe I'll add a screenshot later when the HDD is inserted back into the set-top box :-).

This problem with the increasing RAM usage (by the "enigma2" process) also occurs when the HDD is inserted into the set-top box :-).

#11

Just give logs with an activated SWAP.
That is still missing? once-twice-three times...?

RickX · #12

s3n0 hat geschrieben: 08 Apr 2025 15:12 IThe upper part of "htop" shows the overall memory usage (including system cache/system buffer).

Yes, and on all your screenshots it is obvious that there is no memory problem at all...

#13

Whole log provided by you:

► Text anzeigen

Code: Alles auswählen

Mar  5 06:21:57 vuuno4kse kern.warn kernel: [465661.043843] enigma2 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=-999
Mar  5 06:21:57 vuuno4kse kern.warn kernel: [465661.051820] CPU: 0 PID: 1905 Comm: enigma2 Tainted: P           O    4.1.20-1.9 #1
Mar  5 06:21:57 vuuno4kse kern.warn kernel: [465661.059484] Hardware name: Broadcom STB (Flattened Device Tree)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.065515] [<c0017b58>] (unwind_backtrace) from [<c0013634>] (show_stack+0x10/0x14)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.073360] [<c0013634>] (show_stack) from [<c067c730>] (dump_stack+0x7c/0x90)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.080684] [<c067c730>] (dump_stack) from [<c00a8c88>] (dump_header+0x7c/0x1a0)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.088178] [<c00a8c88>] (dump_header) from [<c00a93f8>] (oom_kill_process+0x2d8/0x498)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.096279] [<c00a93f8>] (oom_kill_process) from [<c00a97fc>] (__out_of_memory+0x244/0x390)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.104727] [<c00a97fc>] (__out_of_memory) from [<c00a9b90>] (out_of_memory+0x6c/0x74)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.112741] [<c00a9b90>] (out_of_memory) from [<c00adb40>] (__alloc_pages_nodemask+0x6ac/0x8a8)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.121536] [<c00adb40>] (__alloc_pages_nodemask) from [<c00a8110>] (filemap_fault+0x174/0x43c)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.130333] [<c00a8110>] (filemap_fault) from [<c00c6850>] (__do_fault+0x38/0x94)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.137913] [<c00c6850>] (__do_fault) from [<c00cad18>] (handle_mm_fault+0xd88/0x1160)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.145927] [<c00cad18>] (handle_mm_fault) from [<c001e8b8>] (do_page_fault+0x104/0x52c)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.154114] [<c001e8b8>] (do_page_fault) from [<c0009364>] (do_PrefetchAbort+0x30/0x90)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.162214] [<c0009364>] (do_PrefetchAbort) from [<c001459c>] (ret_from_exception+0x0/0x24)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.170659] Exception stack(0xcecdffb0 to 0xcecdfff8)
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.175803] ffa0:                                     b033b4a0 afdd7b48 00000000 00000000
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.184075] ffc0: afdd7b48 00000001 b033b4a0 b033b4a0 b6545150 00000000 b5784870 b6545150
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.192347] ffe0: b6545b94 afdd7ae0 b62f45b4 b622fd9c 600d0010 ffffffff
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.199390] Mem-Info:
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.201788] active_anon:161495 inactive_anon:45 isolated_anon:0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.201788]  active_file:691 inactive_file:727 isolated_file:0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.201788]  unevictable:0 dirty:0 writeback:0 unstable:0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.201788]  slab_reclaimable:1084 slab_unreclaimable:2520
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.201788]  mapped:859 shmem:984 pagetables:1108 bounce:0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.201788]  free:2519 free_pcp:298 free_cma:0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.235115] DMA free:11008kB min:8192kB low:10240kB high:12288kB active_anon:268896kB inactive_anon:72kB active_file:1076kB inactive_file:1104kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:350208kB managed:
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.280024] lowmem_reserve[]: 0 0 390 390
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.284605] HighMem free:2084kB min:388kB low:2920kB high:5452kB active_anon:377084kB inactive_anon:108kB active_file:176kB inactive_file:484kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1714176kB managed:
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.328726] lowmem_reserve[]: 0 0 0 0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.332792] DMA: 813*4kB (UEM) 278*8kB (UEMR) 9*16kB (UR) 1*32kB (R) 0*64kB 0*128kB 3*256kB (R) 1*512kB (R) 0*1024kB 0*2048kB 1*4096kB (R) = 11028kB
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.346835] HighMem: 232*4kB (MRC) 47*8kB (MR) 16*16kB (R) 7*32kB (R) 1*64kB (R) 0*128kB 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2104kB
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.360252] 1797 total pagecache pages
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.364274] 0 pages in swap cache
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.367694] Swap cache stats: add 0, delete 0, find 0/0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.373031] Free swap  = 0kB
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.376025] Total swap = 0kB
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.379008] 516096 pages RAM
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.381988] 428544 pages HighMem/MovableOnly
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.386538] 330979 pages reserved
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.389960] 4096 pages cma reserved
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.393550] [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.402203] [  902]     0   902     1530      188       6       2        0         -1000 udevd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.411058] [ 1162]     0  1162      733       55       5       2        0             0 udhcpc
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.419876] [ 1281]     0  1281   134591       74     261       2        0             0 dvb_server
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.429175] [ 1283]     0  1283   129962       56     257       2        0             0 init_client
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.438437] [ 1390]     0  1390     2861       65       6       2        0             0 chronyd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.447497] [ 1394]     0  1394      677       49       4       2        0             0 S90checkinterne
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.457095] [ 1422]     0  1422      530       26       4       2        0             0 dropbear
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.466226] [ 1439]   996  1439      472       52       5       2        0             0 rpcbind
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.475131] [ 1441]   997  1441      565       48       4       2        0             0 dbus-daemon
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.484520] [ 1461]     0  1461      628      109       5       2        0             0 rpc.mountd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.493681] [ 1501]   995  1501      503       38       4       2        0             0 rpc.statd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.502793] [ 1517]     0  1517      733       22       4       2        0             0 inetd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.511565] [ 1521]     0  1521     1040       53       5       2        0             0 bluetoothd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.520876] [ 1526]     0  1526      733       24       5       2        0             0 syslogd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.529794] [ 1531]     0  1531      733       25       5       2        0             0 telnetd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.538825] [ 1536]     0  1536      431       14       4       2        0             0 socketdaemon
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.548170] [ 1541]     0  1541     1391       84       6       2        0             0 vsftpd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.557118] [ 1544]     0  1544      733       24       4       2        0             0 klogd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.565856] [ 1553]     0  1553      733       55       4       2        0             0 udhcpc
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.574810] [ 1559]     0  1559      684       68       3       2        0             0 crond
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.583545] [ 1564]     0  1564      791       70       4       2        0             0 enigma2.sh
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.592842] [ 1571]     0  1571      896       26       3       2        0             0 oscam
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.601577] [ 1575]   999  1575      687       92       4       2        0             0 avahi-daemon
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.611056] [ 1576]     0  1576     4214      502       7       2        0             0 oscam
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.619785] [ 1580]   999  1580      625       39       4       2        0             0 avahi-daemon
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.629233] [ 1581]     0  1581    11540     1718      23       2        0             0 zerotier-one
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.638580] [ 1590]     0  1590     7618      385      18       2        0             0 smbd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.647382] [ 1618]     0  1618     7261      372      17       2        0             0 smbd-notifyd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.656755] [ 1619]     0  1619     7262      372      17       2        0             0 smbd-cleanupd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.666202] [ 1647]     0  1647     9079       65      10       2        0             0 automount
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.675449] [ 1712]     0  1712   177571   155932     345       2        0          -999 enigma2
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.684362] [ 1716]     0  1716     1478       96       6       2        0             0 shellinaboxd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.693846] [ 1717]     0  1717     1478       96       6       2        0             0 shellinaboxd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.703191] [ 1861]     0  1861      452       27       4       2        0             0 wsdd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.711962] [ 1832]     0  1832     1582      155       7       2        0             0 wget
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.720602] [ 1862]     0  1862      733       24       4       2        0             0 run-parts
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.729799] [ 1887]     0  1887     1391       85       5       2        0             0 vsftpd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.738618] [ 1897]     0  1897     1399       90       5       2        0             0 vsftpd
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.747554] [ 1900]     0  1900      530       22       4       2        0             0 dropbear
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.756540] [ 1902]     0  1902      677       24       5       2        0             0 50default
Mar  5 06:21:58 vuuno4kse kern.info kernel: [465661.765724] [ 1908]     0  1908     1391       84       4       2        0             0 vsftpd
Mar  5 06:21:58 vuuno4kse kern.err kernel: [465661.774537] Out of memory: Kill process 1581 (zerotier-one) score 9 or sacrifice child
Mar  5 06:21:58 vuuno4kse kern.err kernel: [465661.782606] Killed process 1581 (zerotier-one) total-vm:46160kB, anon-rss:6872kB, file-rss:0kB
Mar  5 06:21:57 vuuno4kse daemon.info avahi-daemon[1575]: Interface ztmjfm6yzy.IPv6 no longer relevant for mDNS.
Mar  5 06:21:58 vuuno4kse daemon.info avahi-daemon[1575]: Leaving mDNS multicast group on interface ztmjfm6yzy.IPv6 with address ****::****:****:****:****.

Yes, but the log tells:

Code: Alles auswählen

...
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.364274] 0 pages in swap cache
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.367694] Swap cache stats: add 0, delete 0, find 0/0
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.373031] Free swap  = 0kB
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.376025] Total swap = 0kB
...
...
Mar  5 06:21:58 vuuno4kse kern.err kernel: [465661.774537] Out of memory: Kill process 1581 (zerotier-one) score 9 or sacrifice child
Mar  5 06:21:58 vuuno4kse kern.err kernel: [465661.782606] Killed process 1581 (zerotier-one) total-vm:46160kB, anon-rss:6872kB, file-rss:0kB
Mar  5 06:21:57 vuuno4kse daemon.info avahi-daemon[1575]: Interface ztmjfm6yzy.IPv6 no longer relevant for mDNS.
Mar  5 06:21:58 vuuno4kse daemon.info avahi-daemon[1575]: Leaving mDNS multicast group on interface ztmjfm6yzy.IPv6 with address ****::****:****:****:****.
...

with no SWAP activated (SWAP = 0).
I have seen no log with SWAP = 128MB...

And all started with a fault

Code: Alles auswählen

...
Mar  5 06:21:57 vuuno4kse kern.warn kernel: [465661.043843] enigma2 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=-999
..

and a stacktrace (another error in the E2 system] pointing to bad data packages . . .

Code: Alles auswählen

...
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.065515] [<c0017b58>] (unwind_backtrace) from [<c0013634>] (show_stack+0x10/0x14)
...
Mar  5 06:21:58 vuuno4kse kern.warn kernel: [465661.170659] Exception stack(0xcecdffb0 to 0xcecdfff8)
...

And you are right: that stacktrace error can and will not be avoided by a SWAP.
Thats a bad E2 or driver in combination with the rest o the image. Good luck next time with another box.

s3n0 · #14

RickX hat geschrieben: 08 Apr 2025 16:49
s3n0 hat geschrieben: 08 Apr 2025 15:12 IThe upper part of "htop" shows the overall memory usage (including system cache/system buffer).
Yes, and on all your screenshots it is obvious that there is no memory problem at all...

But yes, it's a memory problem. I've already written about that. But I'll write it again. After some time of increasing RAM usage (by the "enigma2" process) the memory is already so overloaded that the entire Linux system gradually crashes and the set-top box becomes uncontrollable via RCU and it is also impossible to connect to the set-top box via the terminal.

In the attached screenshots, you need to use logical reasoning and keep in mind that time is a very important physical quantity. This means that you need to monitor how long the set-top box's uptime runs, which is displayed in the upper part of the htop tool window. I also attached as evidence, a record from dmesg of memory overload messages, when the OOM Kiler tries to free up memory by killing another process with a low priority (in this case, it is the ZeroTier process).

So again:

- dmesg :

Code: Alles auswählen

Mar  5 06:21:57 vuuno4kse kern.warn kernel: [465661.043843] enigma2 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=-999
...
...
...
Mar  5 06:21:58 vuuno4kse kern.err kernel: [465661.774537] Out of memory: Kill process 1581 (zerotier-one) score 9 or sacrifice child
Mar  5 06:21:58 vuuno4kse kern.err kernel: [465661.782606] Killed process 1581 (zerotier-one) total-vm:46160kB, anon-rss:6872kB, file-rss:0kB

- comparison of screenshots (after a few more hours, the RAM was completely full):

RickX · #15

You just don‘t want to believe it…
The yellow part of the memory bar is the „cach / buffee I/O“.
This amount is *not* blocked. It is *available*.

If you please please please call the „free“ command and show the output here.
I‘m pretty sure there will be enough RAM „available“.

You are chasing phantoms. Your crashes are not because of memory leaks. They have another reason.

s3n0 · #16

Just because I didn't include all 30 screenshots I have on my PC doesn't mean I'm lying :). In all cases, the RAM usage by the "enigma2" process ended up being over 550 MB. At that point, the system always froze. The scenario repeated itself several times, including the DMESG dump, where OOM-Killer tries to remove ZeroTier from memory to free up RAM.

If you want to accuse me of looking for phantoms here, I'll leave immediately. If I were stupid and didn't even know the basics of IT, I'd admit that your arguments are of a high level. But that's not the case. Sorry.

For example, the nonsense about "yellow" meaning cache/buffer. I wrote that myself above. So why are you repeating it after me? :) This really doesn't make sense. This system cache/system buffers can be easily cleared in the Linux shell, which I also write above in my shell script:

Code: Alles auswählen

sync; echo 1 > /proc/sys/vm/drop_caches; sleep 1        # clearing system buffers / system caches

If I leave the set-top box in the auto-restart mode of the "enigma2" process every night, then in this case the set-top box runs without problems.

I also regret Papi2000, that it always ignores what I write. I wrote above that I made the same settings, with the same configuration, also this restream, but on another set-top box (Vu+ Zero 4K). But there is no problem with RAM congestion at all. The problem is only in the case of Vu+ Uno 4K SE.

If you think that I am lying or writing nonsense, then I will not write anything more. I check every problem at least 3 times to be sure.

I wanted to help the OpenATV team, so that a developer can take a closer look at the problem. You will remember me only when another user comes forward after some time, with the same problems with Vu+ Uno 4K SE.

What kind of stupidity is it that the "enigma2" process is in 60%+ RAM? Total stupidity. I can understand the use of cache/buffers for large percentages in RAM, but not one separate process ("enigma2"), so much RAM. I know this from the point of view of a system developer! If the RAM usage by one process is so huge, then it means that it is some kind of "variable" that is constantly increasing without checking its capacity. That's why I thought it might be some kind of BUG.

Let everyone solve this problem the way they want. I don't care. I have (partially) solved the problem and the set-top box is no longer freezing. I just wanted to introduce a possible BUG to the OpenATV discussion. If someone wants to claim that RAM usage even above 50% by a single process is okay... then I don't want to be a part of it. I repeat again that I tested restream with the same configuration on other Vu+ (I repeat myself!!!) but there the memory usage by the "enigma2" process remained even after several days, at a ridiculous 200 MB.

I really don't get tired of constantly repeating something over and over again. I de facto solved the problem by restarting enigma2/GUI every night. Since then, the set-top box has not frozen anymore.

I was waiting for help from IT experts (all of you), for an IT expert (for me). Not constant repetition of BASICS of Linux knowledge. This offends me and I really don't need this. I don't have the nerve for it anymore :). Sorry.

Thank you at least for trying to help and for your free time. However, you ruined your free time yourself... by not reading the whole discussion.

s3n0 · #17

So... a small update to the RAM overflow problem in the case of Uno4K SE @ openATV 7.5.1.

Enabling and using the SWAP file did not help, as I claimed and assumed.

In the last screenshot (2025-04-19, 09:40, see below), the terminal connection (PuTTY app / SSH protocol) to the set-top box was already very laggy (with response times of 400-800ms, estimated). It was also impossible to connect to the FTP service/server, because it displayed various errors. So apparently the FTP service/server in the set-top box also crashed, while the terminal connection was still working. Using the RCU, the set-top box refuses to turn on (the TV remains off and therefore the Enigma2 is inoperative).

The solution for my friend is currently a shell script: "/usr/script/e2-auto-restart", with execution rights (chmod 755), started via the CRON scheduler every night:
15 03 * * * /bin/bash /usr/script/e2-auto-restart
The content of the shell script is simple:

Code: Alles auswählen

#!/bin/bash

init 4; sleep 5; killall -9 enigma2 > /dev/null 2>&1
sync; echo 1 > /proc/sys/vm/drop_caches; sleep 1
init 3; sleep 60
wget -qO- "http://127.0.0.1/api/powerstate?newstate=5" > /dev/null 2>&1
echo "$(date '+%Y-%m-%d %H:%M:%S')" > /tmp/e2-auto-restart-via-cron.log

openATV Forum

Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM

Re: Vu+ Uno 4K SE - 'enigma2' process gradually overloads RAM