[Pine64-LTS high kworker load with cpufreq problems after upgrade to 20.02.1]

I had this same problem with kworker processes using 20-50% of CPU at idle.   Tried this method out with cpufreq-set -d 1.15G and immediately the kworker processes cpu utilization dropped.  

 

Question about making the changes permanent at each reboot.  I created the file /etc/default/cpufrequtils like you mentioned.  What do I put in there exactly?  From googling some put:

GOVERNOR="ondemand"
MIN_SPEED="800MHz"
MAX_SPEED="950MHz"

 

Except I would change the MIN_SPEED and MAX_SPEED to the same MAX_SPEED of my cpu (which is 1.15G for pine64+).  I've seen some put GOVERNOR='performance".  Not sure if that line is needed in our case?

 

Note: I just upgraded my pine64+ with 2 gigs ram to the latest stable kernel:

Linux pine64 5.4.28-sunxi64 #20.02.7 SMP Sat Mar 28 17:25:10 CET 2020 aarch64 aarch64 aarch64 GNU/Linux

prior to this I had the date/time issue that was fixed with an old patch from the 3.x legacy kernel era. 

[pine64: massive date/time clock problem]

On 10/4/2019 at 4:25 AM, langerma said:

@ams.br seems like your patch works!

I was able to successfully build with the patch this time as well.   Been running solid since!  Can we get this patch submitted into official builds?

[pine64: massive date/time clock problem]

12 hours ago, ams.br said:

I switched to 5.3.0-rc3, but not work. After +/- 8 days.

 

Welcome to Debian Stretch with Armbian Linux 5.3.0-rc3-sunxi64
System load:   0.82 0.73 0.70  	Up time:       24855 days	

# date
Sat Dec 16 19:19:42 -03 2209

 

This was same for me.

[pine64: massive date/time clock problem]

Problem still persists with the upstream patches.  Been running 5.2.5-sunxi64 and I still get this issue.  Its somewhat more stable on this kernel however if you stop and disable systemd-timesyncd.  Seems like systemd-timesyncd provokes it more.  But I still have to reboot and use ntpdate to sync the time when it flips to year 2114 usually every few days.  Very unreliable.  Yes I have "CONFIG_SUN50I_ERRATUM_UNKNOWN1=y".

 

@sundbry mentioned he applied this patch from the legacy 3.x kernel and has been stable for 1 month

https://github.com/arctype-co/linux/commit/5fcb4e57eeaa4d670ef4acf5818c6fe16aa0d3d0

 

Not sure if this will ever work its way into official builds at this time.  No one else seems to want to talk about the issue in Dev forms.  (I'm no dev). 

Hope to hear about any new progress in this.

[A64 date/time clock issue]

@sundbry I attempted to apply the patch but could never get it to work.  So I actually tried out the 5.2.x kernel and kept  systemd-timesyncd disabled, which seems to work and is stable for me for the past week or so.  As soon as I enable  systemd-timesyncd and start it, it switches the time to year 2114.  Since I don't have much time at the moment keep trying to build a patched kernel I'll keep it this way.  But if anyone has the same problem on the 5.2.x kernel w/  systemd-timesyncd  and is working on trying to solve it I'll be more than happy to supply whatever logs requested to help.

[A64 date/time clock issue]

5 hours ago, sundbry said:

@markolonius I haven't seen this issue in production for over a month on my 7x units I have deployed, after reverting to the method used in the "legacy" kernel branch. Here is the patch. The original patch which is in upstream Linux was a little "too clever", and although I believe it must have worked well for the person who submitted it, the errata in the hardware make it an unreliable fix. The previous technique of just reading the register in a loop until it gets a stable reading works much better.

 

https://github.com/arctype-co/linux/commit/5fcb4e57eeaa4d670ef4acf5818c6fe16aa0d3d0

  

 

This sounds awesome.  Haven't built a kernel for an arm board yet so this should be interesting.  I'll give it a try, but might take me a while due to time.  How would I download this patch? Any plans/hopes of this making it into a nightly or stable release?

[A64 date/time clock issue]

I have this problem very very often.  Running Ubuntu Bionic with Armbian Linux 4.19.57-sunxi64 pretty stable otherwise when time is sync'd.  I disabled systemd-timesyncd and seems to not have the time/date go to year 2114 as much, but still happens 3-4 times per week.  I usually have to manually resync the time using sudo ntpdate 0.north-america.pool.ntp.org.  Sometimes this gives invalid argument and requires me to reboot to run this command.  I'd love to help in any way I can to debug this issue.  Not sure how!

 

I should add I didn't have this issue running arch linux with kernel 4.19 which is odd.  I like armbian much better however and want to stay with it.  Also never had this issue on the ayufan kernels either.

[Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party]

Just downloaded tried out the new pine64 mainline bionic images and get some errors at boot:

 

*** Warning: no boot file name; using 'C0A8917A.img'
Using ethernet@1c30000 device
TFTP from server 192.168.1.1; our IP is 192.168.1.122
Filename 'C0A8917A.img'.
Load address: 0x42000000
Loading: T T T T T T T T T T
Retry count exceeded; starting again
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/01-02-ba-e5-6f-57-fd
Using ethernet@1c30000 device
TFTP from server 192.168.1.1; our IP is 192.168.1.122
Filename 'C0A8917A.img'.
Load address: 0x42000000
Loading: T T T T T T T T T T
Retry count exceeded; starting again
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/01-02-ba-e5-6f-57-fdUsing ethernet@1c30000 device
TFTP from server 192.168.1.1; our IP is 192.168.1.122
Filename 'C0A8917A.img'.
Load address: 0x42000000
Loading: T T T T T T T T T T
Retry count exceeded; starting again

It just keeps repeating.

I apologize if this isn't the proper place to post this.  I appreciate the help and hope this helps.