21 replies to this topic

[aeryn.sun]

Hi,

 

since a few days i see that sometimes the signal/picture gets kind of stuck for a few seconds. first i thought that that was a problem with CAM settings because whenever i selected the menu "CAM settings" enigma crashed. I am able to see the settings but the problem still occurs. I found out that it correlates with this error message in /var/log/messages:

 

Jan  1 01:00:30 et4x00 user.err kernel: ubi0 error: __wl_get_peb: no free eraseblocks

 

I already searched the web for a solution but could not find anything useful.

 

Any help appreciated.

 

box: ET4000

enigma: enigma2 - 2.7+git15129+097ae65-r0.0

cam: enigma2-plugin-softcams-oscam - svn11359-r0.0

pli: nightly

 

Aeryn

[WanWizard]

The filesystem is full.

 

Use the autobackup plugin to make a backup with autoinstall enabled on a fat32 formatted USB stick, download the latest image and unpack it on the same stick, then use it to flash tne box. After the flash, the box will prompt you to restore the backup.

[aeryn.sun]

are you sure? this is what i get with df:

root@et4x00:~# df -h
Filesystem                Size      Used Available Use% Mounted on
ubi0:rootfs             104.7M     69.9M     34.8M  67% /
devtmpfs                114.5M      4.0K    114.5M   0% /dev
tmpfs                    64.0K         0     64.0K   0% /media
tmpfs                   114.7M    264.0K    114.4M   0% /var/volatile
 

[mimisiku]

Maybe a fresh flash will do the trick. Your systemdate is 01-01-00 which means that the datestamo is not loaded from a stream. With an incorrect system date OScam won't start initially (waits for a correct timestamp).
Your df should indicate that enough space is available. Maybe some obscure process running that isn't registering??
Try the top command to see..

[aeryn.sun]

hmm there are some processes which look suspicious. i mean the 'nnnnn' and '[[[[[[' processes.

Mem: 102528K used, 132292K free, 0K shrd, 3K buff, 4K cached

CPU:   0% usr  16% sys   0% nic  83% idle   0% io   0% irq   0% sirq
Load average: 0.07 0.41 0.87 1/70 7425
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
 7425  7231 root     R     2900   1%  11% top
  388   386 root     S    13988   6%   6% /usr/bin/oscam --config-dir /etc/tuxbox/config/oscam --daemon --pidfile /tmp/oscam.pid --restart 2 --utf8
  397   392 root     S    78812  34%   0% /usr/bin/enigma2
  308     1 root     S     6944   3%   0% smbd -D
  318   308 root     S     6944   3%   0% smbd -D
  386     1 root     S     5876   2%   0% /usr/bin/oscam --config-dir /etc/tuxbox/config/oscam --daemon --pidfile /tmp/oscam.pid --restart 2 --utf8
  306     1 root     S     3988   2%   0% nmbd -D
  382     1 avahi    S     3568   2%   0% avahi-daemon: running [et4x00.local]
  383   382 avahi    S     3568   2%   0% avahi-daemon: chroot helper
 7231  7226 root     S     3220   1%   0% -sh
  368     1 root     S     3016   1%   0% /usr/sbin/inetd
  347     1 messageb S     3000   1%   0% /usr/bin/dbus-daemon --system
 7226   355 root     S     2976   1%   0% /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 22
  375     1 root     S     2900   1%   0% /sbin/klogd -n
  373     1 root     S     2900   1%   0% /sbin/syslogd -n -O /var/log/messages
  392     1 root     S     2900   1%   0% {enigma2.sh} /bin/sh /usr/bin/enigma2.sh
  331     1 root     S     2896   1%   0% udhcpc -b -H et4x00 -p /var/run/udhcpc.eth0.pid -i eth0
  355     1 root     S     2720   1%   0% /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 22
  359     1 rpc      S     2700   1%   0% /usr/sbin/rpcbind
  364     1 rpcuser  S     2292   1%   0% /usr/sbin/rpc.statd
    1     0 root     S     1952   1%   0% init [3]
  103     2 root     SW       0   0%   0% [nnnnnnnnnnnnnnn]
    3     2 root     SW       0   0%   0% [ksoftirqd/0]
  105     2 root     SW       0   0%   0% [[[[[[[[[[[[[[[[]
  107     2 root     SW       0   0%   0% [nnnnnnnnnnnn]
  102     2 root     SW       0   0%   0% [nnnnnnnn]
 3656     2 root     SW       0   0%   0% [kworker/0:1]

is this normal?

Edited by aeryn.sun, 28 February 2017 - 19:29.

[WanWizard]

Nothing out of the ordinary here. Those "weird" ones at the bottom are "obscured" processes from the drivers.

[aeryn.sun]

so i reflashed the image, restored the setting but now it is sometimes even worse. the stream freezes very often but this time i have no entry in /var/log/messages. nothing. only thing that helps is a complete restart.

 

enigma2 - 2.7+git15175+95a05df-r0.0
enigma2-plugin-softcams-oscam - svn11359-r0.0

Mem: 100952K used, 133868K free, 0K shrd, 3K buff, 4K cached
CPU:  11% usr  43% sys  21% nic   0% idle   0% io   0% irq  23% sirq
Load average: 2.05 1.80 0.96 3/72 2306
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
  397   392 root     S    77592  33%  75% /usr/bin/enigma2
  103     2 root     SW       0   0%   9% [nnnnnnnnnnnnnnn]
  388   386 root     S    12964   6%   8% /usr/bin/oscam --config-dir /etc/tuxbox/config/oscam --daemon --pidfile /tmp/oscam.pid --restart 2 --utf8
 2245  1376 root     R     3216   1%   3% top
  105     2 root     SW       0   0%   2% [[[[[[[[[[[[[[[[]
    3     2 root     SW       0   0%   2% [ksoftirqd/0]
 1329   355 root     S     2976   1%   1% /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 22
  107     2 root     SW       0   0%   0% [nnnnnnnnnnnn]
   48     2 root     SW       0   0%   0% [kworker/0:2]
  308     1 root     S     6944   3%   0% smbd -D
  318   308 root     S     6944   3%   0% smbd -D
  386     1 root     S     5876   2%   0% /usr/bin/oscam --config-dir /etc/tuxbox/config/oscam --daemon --pidfile /tmp/oscam.pid --restart 2 --utf8
  306     1 root     S     3988   2%   0% nmbd -D
  382     1 avahi    S     3568   2%   0% avahi-daemon: running [et4x00.local]
  383   382 avahi    S     3568   2%   0% avahi-daemon: chroot helper
 1376  1329 root     S     3220   1%   0% -sh
  368     1 root     S     3016   1%   0% /usr/sbin/inetd
  347     1 messageb S     3000   1%   0% /usr/bin/dbus-daemon --system
  376     1 root     S     2900   1%   0% /sbin/klogd -n
  372     1 root     S     2900   1%   0% /sbin/syslogd -n -O /var/log/messages
  392     1 root     S     2900   1%   0% {enigma2.sh} /bin/sh /usr/bin/enigma2.sh
  331     1 root     S     2900   1%   0% udhcpc -b -H et4x00 -p /var/run/udhcpc.eth0.pid -i eth0
  355     1 root     S     2720   1%   0% /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 22
  359     1 rpc      S     2700   1%   0% /usr/sbin/rpcbind
  364     1 rpcuser  S     2292   1%   0% /usr/sbin/rpc.statd
    1     0 root     S     1952   1%   0% init [3]

enigma is eating up 75% of the cpu on a et4000 box. is this also ok?

[Erik Slagter]

Yes that is completely normail.

 

Look at the dmesg output.

Edited by Erik Slagter, 2 March 2017 - 19:12.

[aeryn.sun]

hi,

i attached the dmesg output. the bad blocks entry looks suspicious. but other than that...

Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01

 dmesg.txt   8.69KB   4 downloads

[betacentauri]

Bad block table is normal.

[aeryn.sun]

ok, where can i find older et4000 openpli images, say from beginning of december 2016?

 

A.

[aeryn.sun]

guys, it looks like this problem ist related to network. as soon as i download something on the box, the signal freezes. also when recording and saving on a network share (nfs) the signal freezes. it seems that no extra network module is loaded and thus that the driver is compiled-in in the kernel. Does anyone has experienced this? Any suggestion to resolve this?

 

A.

[WanWizard]

Everything in the box is part of the SoC, and that includes the ethernet hardware. The driver is part of the closed source driver package, there is no separate ethernet driver, and no open source code for that driver.

 

For most boxes, the ethernet hardware is pretty flimsy, even on more high-end boxes like the ET10000. And for all, the drivers are very basic, lacking quite a few features features found in modern day drivers. The most important one being scatter-gather or vectored I/O. This causes the box to over time run out of consecutive free memory blocks (since the driver can't do any decent memory allocation).

 

The more big chunks of data you push through the interface, and the less memory the box has, the sooner this becomes an issue.

[Erik Slagter]

Like I said before this way to another user with similar problem: schedule a nightly reboot every week or more often if necessary.

[Pr2]

Hi Erik,

 

But how end-user can easily schedule such reboot? Nothing is foreseen for it in OpenPLi and cron is not installed by default.

 

If now, users need to schedule a reboot of the box, would be nice to include and easy way to perform it without having to manually install and configure cron.

 

Pr2

[Erik Slagter]

I guess dimitrij can make a plugin as usual

[aeryn.sun]

hi,

thank you for the suggestions. the problem is, that even after a reboot it takes about 15 minutes until the signal starts freezing again. i tried both reboot and enigma reboot only. as for now i would like to get an older image of openpli. am i supposed to open a new thread for that? where can i get older images, is there a ftp server or something?

 

thnx

aeryn

[WanWizard]

We can go about 6 months back, we don't keep older ones, as you can imagine, that would be an awful lot of data to keep online.

[aeryn.sun]

hi,

that would be great. can you provide me the link to the image of say december 1st for et4000?

 

thnx

a.

[WanWizard]

Back online.

 

If you get a 404, wait a while and try again. The file must be synced to the download mirrors. This might take up to an hour (the maximum sync interval).