New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Average load always above 1 #3

Closed
ThomasKaiser opened this Issue Dec 1, 2015 · 17 comments

Comments

Projects
None yet
5 participants
@ThomasKaiser

ThomasKaiser commented Dec 1, 2015

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

This comment has been minimized.

Show comment
Hide comment
@BPI-SINOVOIP

BPI-SINOVOIP Dec 4, 2015

Owner

OK, We will to check it

Owner

BPI-SINOVOIP commented Dec 4, 2015

OK, We will to check it

@ThomasKaiser

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Dec 4, 2015

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!

ThomasKaiser commented Dec 4, 2015

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 comment has been minimized.

Show comment
Hide comment
@bruberg

bruberg Mar 22, 2016

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 commented Mar 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bruberg

bruberg Mar 24, 2016

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

bruberg commented Mar 24, 2016

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

@arnebjarne

This comment has been minimized.

Show comment
Hide comment
@arnebjarne

arnebjarne Mar 24, 2016

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

arnebjarne commented Mar 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Mar 24, 2016

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?

ThomasKaiser commented Mar 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@k0st1x

k0st1x Mar 24, 2016

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

k0st1x commented Mar 24, 2016

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

@arnebjarne

This comment has been minimized.

Show comment
Hide comment
@arnebjarne

arnebjarne Mar 24, 2016

@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).

arnebjarne commented Mar 24, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Mar 24, 2016

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 commented Mar 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Mar 24, 2016

@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 commented Mar 24, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Mar 24, 2016

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.

ThomasKaiser commented Mar 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@arnebjarne

arnebjarne Mar 24, 2016

@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 commented Mar 24, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@arnebjarne

arnebjarne Mar 24, 2016

@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 commented Mar 24, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@arnebjarne

arnebjarne Mar 24, 2016

@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?

arnebjarne commented Mar 24, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Mar 24, 2016

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 commented Mar 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Apr 14, 2016

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 commented Apr 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ThomasKaiser

ThomasKaiser Apr 30, 2016

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!

ThomasKaiser commented Apr 30, 2016

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment