Dietpi: Update M2 kernel, fixes 1.2 freq lock

Created on 22 Jan 2017  路  14Comments  路  Source: MichaIng/DietPi

Most helpful comment

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.

All 14 comments

Available for testing:

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

  1. upgrade to v143 with dietpi-update (including reboot)
  2. dietpi-backup 1 (this saves my sbc)
  3. wget http://dietpi.com/downloads/binaries/nanopi/dietpi_m2_kernel.7z
  4. 7z x -y dietpi_m2_kernel.7z -o/
  5. rm dietpi_m2_kernel.7z
  6. reboot

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 ;)
image

@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

root@NanoPiM214:~#


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

  1. NanoPi M3 @ 1.4 GHz - 09:15 h
  2. Raspberry Pi 3 @ 1.2 GHz - 11:15 h
  3. OrangePi PC Plus @ 1.296 GHz - 13:00 h
  4. NanoPi M1 @ 1.2 GHz - 13:30 h
  5. Raspberry Pi 2 @ 1.0 GHz - 13:45 h
  6. NanoPi M2 @ 1.2 GHz - 16:00 h

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

k-plan picture k-plan  路  3Comments

pgferr picture pgferr  路  3Comments

oshank picture oshank  路  3Comments

Kapot picture Kapot  路  3Comments

bhaveshgohel picture bhaveshgohel  路  3Comments