Backup system 1st:
dietpi-backup 1
Install latest kernel:
wget http://dietpi.com/downloads/binaries/nanopi/dietpi_m2_kernel.7z
7z x -y dietpi_m2_kernel.7z -o/
rm dietpi_m2_kernel.7z
If have problems with that kernel. Networking did not work (either eth0 nor wlan) after this kernel update.
Here are the steps I have done...
As my NanoPiM2 was a headless system, I was not able to connect to it (the usb wlan-stick was not flashing). I powered off the sbc, removed the wlan-stick, connected a lan cable and switched the sbc on again. Same result, networking did not work. Then I have I powered off the sbc, connected a keyboard and hdmi monitor and started the system again. The system boots successfully and the DietPi menu was showed but the IP Address line does not include an ip address. I also was not able to enter the command line prompt.
I have recovered my system using the original files stored in the dietpi-backup, but if needed I would like to test new kernel releases. Thx.
Regards,
Dirk
@dschwarting
Thanks for the results.
USB WiFi may be a lack of firmware, i'll check that.
However, the onboard LAN should be functional, at least it was for me.
Essentially, creating this kernel was a case of following this guide:
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_M2#Make_Your_Own_OS_Image
@dschwarting
I was going to ask which revision board you have, although, mine doesn't state that on PCB. Lets check the lan chip, can you confirm this is the same on your PCB?
Shes a bit dusty ;)
@Fourdee
I also could not find a rev. number on my PCB and the lan chip is completely identical. USB Wifi works pretty reliable with the old Kernel (Asus USB-N10 Nano N150 with Realtek RTL8188CUS chip set / rtl8192cu).
@Fourdee
I've tested the kernel update again using a fresh new installation without wlan (/boot/dietpi.txt: Ethernet_Enabled=1 / Wifi_Enabled=0). However the onboard LAN IS functional even after the kernel update (sorry, please excuse me), but as testet before if wlan is used (/boot/dietpi.txt: Ethernet_Enabled=0 / Wifi_Enabled=1) the wlan support (Asus USB-N10 Nano N150 with Realtek RTL8188CUS chip set / 8192cu module) will be broken after the kernel update.
After installing you kernel update "uname -a" shows...
Linux NanoPiM214 3.4.39-s5p4418 #4 SMP PREEMPT Thu Aug 11 13:54:36 HKT 2016 armv7l GNU/Linux
To test if the new kernel resolves the CPU clock issue I have executed the follwing commands...
root@NanoPiM214:~# cpu
DietPi CPU Info
Use dietpi-config to change CPU / performance options
Architecture | armv7l
Temp | 30'c | Cool runnings.
Governor | performance
Current Freq Min Freq Max Freq
CPU0 | 1400 MHz 400 MHz 1400 MHz
CPU1 | 1400 MHz 400 MHz 1400 MHz
CPU2 | 1400 MHz 400 MHz 1400 MHz
CPU3 | 1400 MHz 400 MHz 1400 MHz
root@NanoPiM214:# cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
1400000 4629
1200000 1
1000000 1
800000 802
700000 0
600000 7
500000 11
400000 210
root@NanoPiM214:# stress -c 4
stress: info: [1508] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd
^C
root@NanoPiM214:# cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
1400000 10542
1200000 6501
1000000 49692
800000 2002
700000 0
600000 7
500000 11
400000 210
root@NanoPiM214:#
As you can see the CPU clock issue is unfortunatelly not resolved (I've a proper cooling).
Using the image...
image name:
nanopi2-ubuntu-mate.img.zip
image date:
2017-01-13 12:55:45
image based on..
Ubuntu 15.04
Kernel: 3.4.39-FriendlyARM Jan 18 [ 2016 !!! ] armv71
the cpufreq is constantly 1,4 GHz.
It seems that the kernel update you have created is using a different kernel...
your kernel update:
Linux NanoPiM214 3.4.39-s5p4418 #4 SMP PREEMPT Thu Aug 11 13:54:36 HKT 2016 armv7l GNU/Linux
nanopi2-ubuntu-mate.img kernel:
3.4.39-FriendlyARM Jan 18 2016 armv71
Regards,
Dirk
@dschwarting
It seems that the kernel update you have created is using a different kernel...
Thanks for the report. I built the official kernel, as per FriendlyARM's process, we can assume "latest" version: http://wiki.friendlyarm.com/wiki/index.php/NanoPi_M2#Make_Your_Own_OS_Image
Kernel: 3.4.39-FriendlyARM Jan 18 [ 2016 !!! ] armv71
the cpufreq is constantly 1,4 GHz.
Strange, if CPU temps are below 80'c~, must be a bug with thermal throttling. Or a possibility that thermal throttling is not functional on the Ubuntu kernel, if not HW controlled on chip.
@dschwarting
Another possibility is that the Ubuntu Kernel may be reporting 1.4GHz, but isn't actually running at that (eg: Odroid C2 2GHz 馃槈 )
Only way to find out is to benchmark CPU on both Ubuntu and DietPi images.
--cpu-max-prime=100000
should take 60 seconds, increase as needed.
apt-get install -y sysbench
sysbench --test=cpu --cpu-max-prime=100000 --num-threads=4 run
@Fourdee
Okay, here are the results...
NanoPiM2 Benchmark:
latest DietPi Kernel:
Linux NanoPiM214 _3.4.39-s5p4418_ #4 SMP PREEMPT Thu _Aug 11_ 13:54:36 HKT _2016_ armv7l GNU/Linux
root@NanoPiM214:~# sysbench --test=cpu --cpu-max-prime=100000 --num-threads=4 run
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 4
Doing CPU performance benchmark
Threads started!
Done.
Maximum prime number checked in CPU test: 100000
Test execution summary:
total time: 1440.5511s
total number of events: 10000
total time taken by event execution: 5761.7820
per-request statistics:
min: 419.63ms
avg: 576.18ms
max: 736.72ms
approx. 95 percentile: 589.04ms
Threads fairness:
events (avg/stddev): 2500.0000/1.73
execution time (avg/stddev): 1440.4455/0.12
Ubuntu 15.04 Kernel:
Linux Ubuntu-mate _3.4.39-FriendlyARM_ #4 SMP PREEMPT Mon _Jan 18_ 13:48:16 HKT _2016_ armv7l armv7l armv7l GNU/Linux
root@Ubuntu-mate:~# sysbench --test=cpu --cpu-max-prime=100000 --num-threads=4 run
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 4
Doing CPU performance benchmark
Threads started!
Done.
Maximum prime number checked in CPU test: 100000
Test execution summary:
total time: 1126.0287s
total number of events: 10000
total time taken by event execution: 4503.1626
per-request statistics:
min: 419.80ms
avg: 450.32ms
max: 1389.48ms
approx. 95 percentile: 551.17ms
Threads fairness:
events (avg/stddev): 2500.0000/8.97
execution time (avg/stddev): 1125.7907/0.14
root@Ubuntu-mate:# cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
_1400000 116657 <-- 1.4 GHz_
1200000 66
1000000 184
800000 115
700000 93
600000 157
500000 249
400000 35211
root@Ubuntu-mate:#
The benchmark result of the ubuntu kernel is about 22% faster (1126s vs. 1440s), which indicates that the cpu frequency is 1.4 GHz.
Dirk
@dschwarting
Thanks for those results, very interesting 馃憤
Is this the same NanoPi M2 device, used in both tests?
@Fourdee
Yes. Same Device, same active cooling, same environment (I have only changed the sdcard).
I'm crunching workunits for Einstein@home with various devices. None is so bad as the NanoPi M2 device and this is really disappointing. Why? Because the NanoPi M3 is my best device. They have similar cpu's (M2: S54418 0.4-1.4 GHz vs. M3: S56818 0.4-1.4 GHz) but the cpu performance is as different as day and night. This must be a software (kernel) problem. Each workunit needs to calculate 17500 GFLOPS, see the times (in hh:mm) to finish a single workunit for my devices...
I hope to receive a ASUS Tinker board this month, a very exiting device. I hope to get a new number one board ;-)
Dirk
I hope to receive a ASUS Tinker board this month, a very exiting device. I hope to get a new number one board ;-)
Aye, looks a good spec board. Still on my wish list :)
Yes. Same Device, same active cooling, same environment (I have only changed the sdcard).
We might be able to pull off the kernel, uboot from the Ubuntu image, then test on DietPi image and see if that resolves the drop in clocks. Will take a look when I can.
We might be able to pull off the kernel, uboot from the Ubuntu image, then test on DietPi image
and see if that resolves the drop in clocks. Will take a look when I can.
That's cool! No need to hurry. If it's ready, I'll be there to test it.
Thx!
Dirk
I've testet the latest DietPi image v145 for NanoPi M2 devices to see if the "NanoPi M2 stucks at 1GHz" bug persists. It did persist. Here are the results...
V145 | NanoPi M2/T2 (armv7l)
root@DietPiTest:~# uname -a
Linux DietPiTest 3.4.39-s5p4418 #4 SMP PREEMPT Thu Aug 11 13:54:36 HKT 2016 armv7l GNU/Linux
cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
1400000 1380
1200000 3
1000000 5
800000 2
700000 0
600000 5
500000 8
400000 26590
root@DietPiTest:~# stress -c 4
stress: info: [1324] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd
^C
root@DietPiTest:~ cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
1400000 11714
1200000 3
1000000 116638 <-- !!! only 1 GHz !!!
800000 2002
700000 0
600000 5
500000 8
400000 27958
root@DietPiTest:~
Also the sysbench result is bad...
sysbench --test=cpu --cpu-max-prime=100000 --num-threads=4 run
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 4
Doing CPU performance benchmark
Threads started!
Done.
Maximum prime number checked in CPU test: 100000
Test execution summary:
total time: 1460.4199s
total number of events: 10000
total time taken by event execution: 5841.2672
per-request statistics:
min: 419.68ms
avg: 584.13ms
max: 737.34ms
approx. 95 percentile: 589.22ms
Threads fairness:
events (avg/stddev): 2500.0000/1.73
execution time (avg/stddev): 1460.3168/0.06
because it is much slower as the benchmark result of the ubuntu kernel.
Dirk
General cleanup of outdated/no-progress tickets.
Please reopen if required.
Most helpful comment
Aye, looks a good spec board. Still on my wish list :)
We might be able to pull off the kernel, uboot from the Ubuntu image, then test on DietPi image and see if that resolves the drop in clocks. Will take a look when I can.