Average load always above 1

[ThomasKaiser]

Since the kernel you're now using with the A83T is as old as the one Cubieboards started with... might this be related: http://www.cubieforums.com/index.php/topic,1084.0.html ?

[BPI-SINOVOIP]

OK, We will to check it

[ThomasKaiser]

WTF? Why do you close this issue without resolving (not even investigating what's wrong)? I just did an 'git pull' to get your latest commits and gave it a try: Nothing has changed, average load still above 1. There's something wrong, guys!

[bruberg]

This problem still exists with all images I've tried, the latest being Ubuntu Mate 15.10 for BPI-M3 GPU PowerVR SGX544MP (20160317)

[bruberg]

Also a problem with the latest Debian image: Debian 8.3 Jessie Mate for BPI-M3 GPU PowerVR SGX544MP (20160322)

[arnebjarne]

I have the same issue on a cross-compiled kernel using the latest github code from BPI. So problem is still in kernel code.

[ThomasKaiser]

Set this to 0 and you're done.

@BPI-SINOVOIP it's really unbelievable you didn't fix that in the meantime. You must really hate your work and Banana Pi users, right?

[k0st1x]

@ThomasKaiser thank you for help. @BPI-SINOVOIP can you validate this fix and apply it to config file and image?

[arnebjarne]

@ThomasKaiser I can confirm that setting

[usbc0]
usb_detect_type = 0

in either ./BPI-M3-bsp/sunxi-pack/chips/sun8iw6p1/configs/*/sys_config.fex

and do a recompile using ./build and then rewrite the bootloader (u-boot.fex and boot.fex) on the SD card using:

sudo dd if=./BPI-M3-bsp/output/*/pack/u-boot.fex of=/dev/mmcblk0 bs=1k seek=19096
sudo dd if=./BPI-M3-bsp/output/*/pack/boot.fex of=/dev/mmcblk0 bs=1k seek=86016
sudo reboot

fixed the problem on my BPI M3 (substitute * with chosen model ie. BPI-M3_720P).

[ThomasKaiser]

can you validate this fix and apply it to config file and image?

LOL, and then all BPi M3 users have to throw away the installations they currently use to burn a new image to SD card or eMMC? Since in the meantime they started to understand how u-boot works (woohoo!) so using their latest kernel/u-boot package you can make use of script.bin available on the 1st partition instead and simply fix it there yourself without recompiling the whole crappy BSP.

BTW: If you have a look at the 1st link when I reported the issue then you'll realize that I already delivered the solution. But since we're not dealing with a vendor respecting his customer base but with SinoVoip instead it's as usual when incompetence meets ignorance.

[ThomasKaiser]

@arnebjarne I know, the image I provided all the time for you unfortunate M3 users has this fixed since 2nd Dec 2015: http://linux-sunxi.org/Banana_Pi_M3#Images

[ThomasKaiser]

BTW: I hope you all know that this 'problem' is just a cosmetical issue since average load (a concept a bit weird/useless and by most if not all people completely misunderstood) exceeded 1 since one process was always in D state (this adds to the average load but doesn't hurt at all).

But that SinoVoip simply ignores such issues is a clear indication that they have no clue how their stuff works. I provided an easy to use monitoring solution and if they would've used that internally they would both know that there's an issue with average load and also know that the M3 needs a heatsink since otherwise throttling occurs even with light workloads. Have you ever seen a single image of any of their boards with a heatsink applied? Me not and I would suspect they simply have not the slightest idea about the relevance of throttling regarding performance.

Same with the crappy DC-IN connector. They used a quality barrel connector when developing the board on all pre-production samples just to replace it with this shitty connector leading to all sorts of undervoltage/undercurrent trouble with the first production batch.

I really doubt they are able to imagine what their customers want and what they experience all the time.

[arnebjarne]

@ThomasKaiser - Ah, great. I will have a look at your scripts right now. using /boot (part 1) is one thing im looking forward to :)

[arnebjarne]

@ThomasKaiser unfortunable I brought the board in blindness and now I have the board and I will try making the best of it. I brought the board to build my own little Koji rpm build farm. I cannot afford the Gigatebyte MP30-AR0 :-D.

[arnebjarne]

@ThomasKaiser do you have your source code for the 3.4.42 kernel available? I prefer to compile the code myself for security reasons (no offence ;) ). Latest source in the 3.4.x-train is 3.4.111. Might be worth bumping the kernel up there?

[ThomasKaiser]

Allwinner's BSP for A83T and H3 is pretty similar so I just let our Armbian patches start to apply (and it broke at 3.4.43 that's why I ended up lazily at 3.4.42 ;): https://github.com/igorpecovnik/lib/tree/master/patch/kernel/sun8i-default

You should be aware that a newer BSP variant has been released by Allwinner recently: https://github.com/friendlyarm/h3_lichee

Unfortunately the whole commit log is missing and I doubt that SinoVoip will publish the sources they got from Allwinner in the meantime ever (I would suspect they made the same for A83T available). But it seems a lot has changed so if you touch this crappy 3.4.x kernel stuff then I would have a look into.

Since you mentioned security: Using then Allwinner's BSP kernel is a bad joke. Put the M3 in the drawer for a year (to wait for Mainline support becoming useable) or simply throw it away.

[ThomasKaiser]

Anyone wants to join in? Providing a community OS image that doesn't suck: http://forum.banana-pi.org/t/bpi-m3-new-image-bpi-m3-ubuntu-16-04-beta-mate/1440/15

I'm already done, flashed my Hybrid Armbian/SinoVoip image on eMMC and enjoy now Jessie on the M3 having to fear a bit less security issues.

[ThomasKaiser]

LOL, I spoke about 'less security issues'. Have a look at the funny kernel 'Team BPi' provides:

tk@bananapim3:~$ id
uid=1000(tk) gid=1000(tk) groups=1000(tk),20(dialout),27(sudo),29(audio),44(video),46(plugdev),108(netdev)
tk@bananapim3:~$ echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug 
tk@bananapim3:~$ id
uid=0(root) gid=0(root) groups=0(root),20(dialout),27(sudo),29(audio),44(video),46(plugdev),108(netdev),1000(tk)

su without authentication for everyone!