wahlm

Thanks for the suggestion! I just forked the repo and will provide a PR.

I put some fresh armbian buster image to my cubieboard (1). Although no (real) application was installed, a load of around 20-30% could be seen. First I located the K-worker problem on A20 based boards thread and blacklisted sun4i_gpadc and sun4i_gpadc_iio. But after removing my display and booting the system still there was some kworker load almost stopping the system every 5-10 seconds. Digging deeper I found a description and a possible solution of the problem. Looking a my Olimex A20 Lime2 which I am currently testing with the new olimage by Olimex because of the never solved gigabit problems of my board, the same behaviour could be seen. The modules sun4i_gpadc and sun4i_gpadc_iio were already blacklisted, but the headless system showed the same kworker activity. I tried the suggestion and removed the sun4i_drm_hdmi module and immediately the kworker activity stopped and load went down to almost 0. Unfortunately the stock armbian kernel image configures CONFIG_DRM_SUN4I_HDMI not as module. So I had to build my own kernel with setting CONFIG_DRM_SUN4I to m. Then I could remove the sun4i_drm_hdmi module, too. I saw the expected behaviour: The kworker activities are gone and load went down to almost 0. So my suggestion is to change the stock kernel configuration for CONFIG_DRM_SUN4I to module. Then headless users can blacklist the module sun4i_drm_hdmi and don't need to build their own kernels.

Hi, unattended-upgrade is active by default. So updates (except kernel) are installed automatically. Have a look at /var/log/apt/history.log* for the installation history. Bye, wahlm From my a20lime2 jessie headless server: Start-Date: 2016-12-14 06:31:10 Commandline: /usr/bin/unattended-upgrade Upgrade: apt:armhf (1.0.9.8.3, 1.0.9.8.4), libapt-pkg4.12:armhf (1.0.9.8.3, 1.0.9.8.4), apt-utils:armhf (1.0.9.8.3, 1.0.9.8.4), libapt-inst1.5:armhf (1.0.9.8.3, 1.0.9.8.4), apt-transport-https:armhf (1.0.9.8.3, 1.0.9.8.4) End-Date: 2016-12-14 06:31:25 Start-Date: 2016-12-24 06:38:47 Commandline: /usr/bin/unattended-upgrade Upgrade: libxml2:armhf (2.9.1+dfsg1-5+deb8u3, 2.9.1+dfsg1-5+deb8u4) End-Date: 2016-12-24 06:38:49

Hi, from what I read in the github PR, it seems I am more among the lucky 10% with a a20lime2 board running reliably at 480 Mhz . But I always prefer reliability to speed, so I have no problem that the configuration is changed to 100% of the boards running reliably! My board even gets more reliable then . Bye, wahlm

Hi, yes, I still use the 3.4 kernel and blanking the HDMI improved the benchmark results a lot. So the values are even better than tkaiser's. Maybe his results were influenced by HDMI output, too. Find my new tinymembench results for the a20lime2 below. Bye, wahlm

Hi, again thanks for the hint. It seems I missed a lot of already available info . But my boards worked reliably up to now, so there was no need to dig into investigation. Anyway, here are the results of the improved version of a10-meminfo for the a20lime2. Seems the (already existing) values of the older version are still reliable. Bye, wahlm a20lime2:~/a10-dram-tools# ./a10-meminfo dram_clk = 480 mbus_clk = 300 dram_type = 3 dram_rank_num = 1 dram_chip_density = 4096 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7b (0x5294a00) dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 dqs_gating_delay = 0x05050505 active_windowing = 0

Hi, ok, thanks for the hint! From what I remember, I did not set that option and therefore it is/was part of the armbian default config. Anyway I removed it from the kernel cmdline of my a20lime2 and ran lima-memtester 100M without a problem for about 80 minutes. As it is a headless system I could not check the cube animations, but no error was reported at the (ssh-)console and there were 5 full loops reached at this time. I then cancelled the test to check the DRAMs on the board. It has Samsung K4B4G1646D-BCK0 (datecode 516) assembled. In addition I saw that I placed a heatsink to the A20 (forgot about that...). The board is housed in the standard Olimex plastic case. My board is Rev.C. Bye, wahlm

Hi, as an addition here are the a10-meminfo results from my CubieBoard 1 and CubieTruck both running cubian. At least the CubieTruck shows a lower dram_clk. Both systems run 24h/7d since a long time (1-2 years) without problems and have 2,5" HDDs attached via SATA. But it has to be verified that the results of a10-meminfo are reliable... Bye, wahlm root@cubie:~/a10-meminfo# ./a10-meminfo dram_clk = 480 dram_type = 3 dram_rank_num = 1 dram_chip_density = 4096 dram_io_width = 16 dram_bus_width = 32 dram_cas = 6 dram_zq = 0x7b dram_odt_en = 0 dram_tpr0 = 0x30926692 dram_tpr1 = 0x1090 dram_tpr2 = 0x1a0c8 dram_tpr3 = 0x0 dram_emr1 = 0x0 dram_emr2 = 0x0 dram_emr3 = 0x0 root@ctruck:~/a10-meminfo# ./a10-meminfo dram_clk = 432 dram_type = 3 dram_rank_num = 1 dram_chip_density = 8192 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7f dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0

Hi, I just tried a10-meminfo on my stable a20lime2 and a10lime with the old u-boot versions (see below). Funny thing is that the tool is reporting 480 Mhz for both systems! I tried running lima-memtester, but both systems are server/headless and use sunxi_no_mali_mem_reserve in kernel command line. So lima-memtester is terminating at start. The question is why my a20lime2 tinymembench results compared to the results of tkaiser's are showing a lower performance. Maybe there are some other parameters beside the dram_clk involved? Or does it depend on the type/vendor of RAM used on the board? Bye, wahlm root@a10lime:~/a10-meminfo# ./a10-meminfo dram_clk = 480 dram_type = 3 dram_rank_num = 1 dram_chip_density = 4096 dram_io_width = 16 dram_bus_width = 16 dram_cas = 6 dram_zq = 0x7b dram_odt_en = 0 dram_tpr0 = 0x30926692 dram_tpr1 = 0x1090 dram_tpr2 = 0x1a0c8 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x0 dram_emr3 = 0x0 a20lime2:~/a10-meminfo# ./a10-meminfo dram_clk = 480 dram_type = 3 dram_rank_num = 1 dram_chip_density = 4096 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7b dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0

Hi, I installed my a20lime2 in october 2015 (it was Armbian_4.5_Lime2_Debian_jessie_3.4.109) and although not highly loaded worked since then without a single problem or crash. So I was quite astonished about the problems reported in this thread. I frequently updated the system using aptitude. So I tried to find out why my system is working stable. I have a 2,5" HDD connected via SATA and I had done a rsync of around 600GB to the a20lime2 short time ago and it succeeded without a problem. Anyway, I found out that although the deb-packages for kernel, firmware and root filesystem were installed and so updated regularily, the u-boot deb-package was not installed! So I found out that I still use the u-boot of the installation image: a20lime2:~/tinymembench# dd if=/dev/mmcblk0 bs=48K count=1 | strings | grep -i "U-Boot" 1+0 records in 1+0 records out 49152 bytes (49 kB) copied, 0.0081478 s, 6.0 MB/s U-Boot U-Boot SPL 2015.07-armbian-sun7i (Oct 11 2015 - 16:53:01) U-Boot 2015.07-armbian-sun7i for I thought the missing u-boot deb-package was my fault, but I checked my armbian a10lime (first install with Armbian_5.00_Lime-a10_Debian_jessie_3.4.110) and found it missing there, too. It still had U-Boot SPL 2016.01-armbian-sun7i (Feb 10 2016 - 20:08:59) installed. So either I did something systematically wrong or the deb-package was not installed on these old images. Maybe this can explain why users with old and updated installations (like me) don't see the problem. I added my tinymembench results at the bottom. Comparing the results, it confirms that my board is running at a lower DRAM-speed than tkaiser's. Bye, wahlm

Hi Baos, the mac address is not invalid, but it is marked as a locally administered address. The mac addresses devices usually get from their manufacturer are universally administered addresses. So it seems the SW on your router doesn't like these perfectly valid addresses. I fear Igor doesn't have an Organizationally Unique Identifier (OUI) to create UAA mac addresses , so LAA is the correct way to go. Bye, wahlm

Hi Igor and all, after running armbian on my A20 lime2 for a long time, I decided to switch to armbian on my A10 lime, too (from jessie with a eewiki-based self-compiled kernel). So far it works as perfect as the A20, but there are two small and funny things with the Armbian_5.00_Lime-a10_Debian_jessie_3.4.110.zip image I used: After login the nice armbian banner stated that my A10 lime is a cubieboard . I have a cubieboard, too. So I double checked... The problem is located in /etc/init.d/armhwinfo, There all "sun4i" boards are simply "Cubieboard". I had to adapt the LED check which is used to detect Lime and Lime2 a bit and added the Lime A10. I checked the LEDs path on my cubian based cubieboard 1 and it was different, so hopefully the LED check correctly detects the Lime A10. During test (restarting service armhwinfo) I saw that the detected ID is appended to /var/run/machine.id. I had a funny banner with Cubieboard and 2 times Lime A10 . Here is what I changed finally: --- armhwinfo.org 2016-02-11 23:58:47.000000000 +0100 +++ armhwinfo 2016-04-07 12:17:16.848138250 +0200 @@ -17,6 +17,8 @@ HARDWARE=$(cat /proc/cpuinfo | grep Hardware | awk '{print $3}') GMAC=$(dmesg | grep "sun6i_gmac") LEDS=$(dmesg |grep "green:ph02:led1") +# a10 lime +LEDS2=$(dmesg |grep "green:ph2:led1") TERMINUS=$(lsusb | grep "1a40:0101") SWITCH=$(dmesg | grep "BCM53125") INTERUPT=$(cat /proc/interrupts | grep "eth0") @@ -55,8 +57,12 @@ ID="Orange H3" fi if [ $HARDWARE = "sun4i" ] || [ $HARDWARE = "Allwinner" ]; then + if [ "$LEDS2" != "" ]; then + ID="Lime A10" + else ID="Cubieboard" fi + fi if [ $HARDWARE = "sun7i" ] || [ $HARDWARE = "Allwinner" ]; then # redistribute irq to dedicated core if [ "$INTERUPT" != "" ] && [ "$CORES" -gt 1 ]; then @@ -115,7 +121,7 @@ if [[ $MACHINE == *M2* ]]; then ID="Banana M2"; fi echo -e "[\e[0;32m ok \x1B[0m] Starting ARM hardware info: $ID" -echo $ID >> /var/run/machine.id +echo $ID > /var/run/machine.id ;; stop|reload|restart|force-reload|status) echo -e "[\e[0;32m ok \x1B[0m] Stopping ARM hardware info ..." The second issue was an (compared to the A20) incredibly high temperature: 72,2. I checked /etc/update-motd.d/30-sysinfo and found out that although it is commented as "only on A20", the a20-tp-hwmon reading is available at the A10 lime, too. Whatever this value is, the correct temperature seems to be at i2c. I got a 37,8 there. So I commented out the A20 temp reading, but this is surely just a quick hack... --- 30-sysinfo.org 2016-02-11 23:58:47.000000000 +0100 +++ 30-sysinfo 2016-04-06 23:06:55.713259579 +0200 @@ -106,9 +106,9 @@ fi # if we are reading from A20 -if [ -d "/sys/devices/platform/a20-tp-hwmon/" ]; then - board_temp=$(cat /sys/devices/platform/a20-tp-hwmon/temp1_input | awk '{printf("%d",$1/1000)}') -fi +#if [ -d "/sys/devices/platform/a20-tp-hwmon/" ]; then +# board_temp=$(cat /sys/devices/platform/a20-tp-hwmon/temp1_input | awk '{printf("%d",$1/1000)}') +#fi # where it should be if [ -d "/sys/devices/virtual/thermal/thermal_zone0/" ]; then Finally I want to send you a big thank you for providing armbian! Bye, wahlm