Applications

Calendar

Everything posted by piknew

Please post dmesg output after changes are committed to emmc (with "w"). I had exactly the same issue - dmesg was reporting a lot of serious write errors. I already assumed that emmc is not usable anymore, however, after couple of weeks... I tried again and everything was OK. I am not sure if this was really hardware issue or software.
So, please check dmesg output...

Could you please point out how to achieve this? All my H3 (also H2+) devices suffer from the issue as described. Even with newest kernel. So, after reading I decided to test stability with "constant cpu frequency".
EDIT: I've done it by:
[root@PKTEST ~]# cat /etc/default/cpufrequtils
# WARNING: this file will be replaced on board support package (linux-root-...) upgrade
ENABLE=true
MIN_SPEED=408000
MAX_SPEED=1296000
#GOVERNOR=ondemand
GOVERNOR=performance
[root@PKTEST ~]#
Question: would it be possible not to overwrite cpufrequtils file once support package is installed/upgraded?

Thanks, I have updated device-tree-compiler to "buster" version and I have created symbolic link from modules/... to dtc binary. Script armbian-add-overlay is working. But after compiling new dts - rtc is still not working (not registered as rtc device).

My plan is (on Friday - when I get physical access to device):
1. Unplug network cable and plug in into built-in eth0 port if successful then get logs/dmesg etc.
2. Move the device neat to PC (or laptop near to this board), connect by UART and try to login (of course I know that it is without initial login prompt). Fortunately I am using portable UPS, so there should be no issue.
Any more suggestions? As topic is basically related to other (unfortunately other users the do not confirmed if connect by ssh is working (without debug option it seems that connection is not done at all).

Sure. I will treat it as warning - do not use "stop" for this service. If there is relable way to recognise if "stop" is done on behalf of shutdown then it would be good idea to add it here as condition... I guess it is EOT for this "issue".
How about the test that I've done here: https://forum.armbian.com/topic/7548-apt-list-vs-mainline-very-slow/?do=findComment&amp;comment=56805
I can repeat it, however as "apt" itself is a binary - I do not know what is really done by this tool here (no child processes, eg gzip etc.)...

Please see attached log.txt.
This is the sequence of operations to reproduce (on my Orange Pi+2 in this case). Important is that removal or restore of /etc/apt/apt.conf.d/02-armbian-compress-indexes file shall be followed by apt update command.
Result of armbianmonitor -u is here.
Edit 1: my Opi+2 just "died" (this part of post shall be probably moved to new topic I guess). Igor, can you please try following? I was able to "make unresponsible" my both Opi+ and now OpiZero:
Starting point - armbian-hardware-monitor was disabled wg. no related symlink in /etc/systemd/.... // Please do not ask why I disabled it . Enabling it was caused by message in armbianmonitor -u - so, next is what I did.
root@PKOTHER:~# systemctl enable armbian-hardware-monitor
Created symlink from /etc/systemd/system/basic.target.wants/armbian-hardware-monitor.service to /lib/systemd/system/armbian-hardware-monitor.service.
root@PKOTHER:~# systemctl start armbian-hardware-monitor
root@PKOTHER:~# systemctl stop armbian-hardware-monitor
Interesting thing is that "PuTTY" is keeping connection (by means of TCP?) // as it is seen first I was trying to connect to "pkhelper" (OPi+2 which stop responding after commands as given above and is a subject of my my tests for armbiuanmonitor -u):
Last command was not completed. And device... in not accessible anymore. I was able to reproduce it wit both OP'is.
admin@PKSERVER:~$ ssh root@pkother
ssh: connect to host pkother port 22: No route to host
Edit 2: now both of my "servers" are restarted, so I can resume testing...

Actually I have found root cause of this slowness. It is a file:
/etc/apt/apt.conf.d/02-armbian-compress-indexes
After removing it - everything is very fast again. So, the issue is rather not related to kernel. It is related to Armbian support files (in my case the version is 5.47).

After upgrade two of my boards to mainline (4.14.51-sunxi) I have noticed that simple command
apt list
basically stopped working. It stuck at "Listing ..." (at this moment 1 core of CPU is utilized in 100%). Now I run it in background to see if eventually it will be completed... So far (15 minutes)... nothing.
apt list --installed
is also very slow, but after some time it gives results. However, it is much slower than on "default" (3.4.113-sun8i)
Can anybody check it and reconfirm?