* Armada 3720 cpufreq bug: request for testing (EspressoBIN, uDPU, ...) @ 2020-10-09 10:57 Marek Behún 2020-10-12 5:19 ` Andre Heider 0 siblings, 1 reply; 3+ messages in thread From: Marek Behún @ 2020-10-09 10:57 UTC (permalink / raw) To: arm Cc: Tomasz Maciej Nowak, Luka Perkov, Gregory CLEMENT, Andre Heider, soc, Vladimir Vid, Russell King, Gérald Kerma, Miquel Raynal, Konstantin Porotchkin, pali, linux-arm-kernel Hello, I have a request for testing some patches that fix cpufreq issues on Armada 3720 (EspressoBIN, uDPU, Devel Board, maybe others?). It concerns top 4 commits of branch a3720-cpufreq-issues of repository https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/ (log at https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/log/?h=a3720-cpufreq-issues) We've discovered a bug in Armada 3720 cpufreq driver that causes base CPU frequency to drop to 800 MHz on systems configured to 1 GHz. More info here: https://www.spinics.net/lists/arm-kernel/msg844752.html The patchset above led us to discover another bug, in the SOC itself, that causes the CPU to behave weirdly when frequency changes to 1 GHz. A similar erratum is documented by Marvell but only for systems where base frequency is 1.2 GHz. We've discovered that to make cpufreq scaling stable on Armada 3720 on systems with base frequency 1 GHz, we also have to set voltage levels for L1, L2 and L3 loads to 1108 mV. (We were led to this by patch we found here https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/page/2/?tab=comments#comment-80012). We would like you to build this sources and test the ondemand cpufreq governor on systems with variable CPU load, for at least 1 day (more is better). If you could also test the userspace governor and randomly change frequency, it would be great. Please let me know if and when you are willing to do this. Thank you. Marek & Pali _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Armada 3720 cpufreq bug: request for testing (EspressoBIN, uDPU, ...) 2020-10-09 10:57 Armada 3720 cpufreq bug: request for testing (EspressoBIN, uDPU, ...) Marek Behún @ 2020-10-12 5:19 ` Andre Heider 2020-10-26 14:54 ` Pali Rohár 0 siblings, 1 reply; 3+ messages in thread From: Andre Heider @ 2020-10-12 5:19 UTC (permalink / raw) To: Marek Behún, arm Cc: Tomasz Maciej Nowak, Luka Perkov, Gregory CLEMENT, soc, Vladimir Vid, Russell King, Gérald Kerma, Miquel Raynal, Konstantin Porotchkin, pali, linux-arm-kernel Hi Marek, On 09/10/2020 12:57, Marek Behún wrote: > I have a request for testing some patches that fix cpufreq issues on > Armada 3720 (EspressoBIN, uDPU, Devel Board, maybe others?). > > It concerns top 4 commits of branch a3720-cpufreq-issues of repository > https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/ > > (log at https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/log/?h=a3720-cpufreq-issues) > > We've discovered a bug in Armada 3720 cpufreq driver that causes > base CPU frequency to drop to 800 MHz on systems configured to 1 GHz. > More info here: > https://www.spinics.net/lists/arm-kernel/msg844752.html > > The patchset above led us to discover another bug, in the SOC itself, > that causes the CPU to behave weirdly when frequency changes to 1 GHz. > A similar erratum is documented by Marvell but only for systems where > base frequency is 1.2 GHz. > > We've discovered that to make cpufreq scaling stable on Armada 3720 > on systems with base frequency 1 GHz, we also have to set voltage levels > for L1, L2 and L3 loads to 1108 mV. (We were led to this by patch we found here > https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/page/2/?tab=comments#comment-80012). > > We would like you to build this sources and test the ondemand cpufreq > governor on systems with variable CPU load, for at least 1 day (more is better). > If you could also test the userspace governor and randomly change frequency, > it would be great. > > Please let me know if and when you are willing to do this. Thanks for hunting this one down! I've applied your 4 patches to v5.9 and gave it a quick spin. I'm using schedutil, which had the very same issue. It never actually switched to 1000mhz. It claimed it did, but the `mhz` util as well as the 7z benchmark proved it never used anything >800mhz. Before: $ 7z b 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 793 793 794 793 794 792 793 794 RAM size: 985 MB, # CPU hardware threads: 2 RAM usage: 441 MB, # Benchmark threads: 2 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 711 149 464 692 | 17501 194 770 1494 23: 708 155 465 722 | 17595 198 770 1523 24: 682 158 464 734 | 17079 196 764 1499 25: 663 160 473 757 | 15595 189 734 1388 ---------------------------------- | ------------------------------ Avr: 156 466 726 | 194 760 1476 Tot: 175 613 1101 After: $ 7z b 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 992 998 998 994 996 997 997 997 RAM size: 987 MB, # CPU hardware threads: 2 RAM usage: 441 MB, # Benchmark threads: 2 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 866 151 559 843 | 22334 198 962 1907 23: 872 152 584 889 | 21809 197 959 1888 24: 808 145 599 869 | 11413 110 915 1002 25: 716 137 596 819 | 21092 198 949 1877 ---------------------------------- | ------------------------------ Avr: 146 585 855 | 176 946 1669 Tot: 161 765 1262 The measured frequency as well as the performance data finally looks good, so: Tested-by: Andre Heider <a.heider@gmail.com> Thanks, Andre _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Armada 3720 cpufreq bug: request for testing (EspressoBIN, uDPU, ...) 2020-10-12 5:19 ` Andre Heider @ 2020-10-26 14:54 ` Pali Rohár 0 siblings, 0 replies; 3+ messages in thread From: Pali Rohár @ 2020-10-26 14:54 UTC (permalink / raw) To: Andre Heider Cc: Marek Behún, Tomasz Maciej Nowak, Luka Perkov, Gregory CLEMENT, soc, Vladimir Vid, Russell King, arm, Gérald Kerma, Miquel Raynal, Konstantin Porotchkin, linux-arm-kernel On Monday 12 October 2020 07:19:48 Andre Heider wrote: > Hi Marek, > > On 09/10/2020 12:57, Marek Behún wrote: > > I have a request for testing some patches that fix cpufreq issues on > > Armada 3720 (EspressoBIN, uDPU, Devel Board, maybe others?). > > > > It concerns top 4 commits of branch a3720-cpufreq-issues of repository > > https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/ > > > > (log at https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/log/?h=a3720-cpufreq-issues) > > > > We've discovered a bug in Armada 3720 cpufreq driver that causes > > base CPU frequency to drop to 800 MHz on systems configured to 1 GHz. > > More info here: > > https://www.spinics.net/lists/arm-kernel/msg844752.html > > > > The patchset above led us to discover another bug, in the SOC itself, > > that causes the CPU to behave weirdly when frequency changes to 1 GHz. > > A similar erratum is documented by Marvell but only for systems where > > base frequency is 1.2 GHz. > > > > We've discovered that to make cpufreq scaling stable on Armada 3720 > > on systems with base frequency 1 GHz, we also have to set voltage levels > > for L1, L2 and L3 loads to 1108 mV. (We were led to this by patch we found here > > https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/page/2/?tab=comments#comment-80012). > > > > We would like you to build this sources and test the ondemand cpufreq > > governor on systems with variable CPU load, for at least 1 day (more is better). > > If you could also test the userspace governor and randomly change frequency, > > it would be great. > > > > Please let me know if and when you are willing to do this. > > Thanks for hunting this one down! > > I've applied your 4 patches to v5.9 and gave it a quick spin. Hello! I have there a new version of Armada 3720 CPU patches. They are in branch "a3720-cpufreq-issues" at my git repository: https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git Full commit log is here: https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=a3720-cpufreq-issues The main difference from previous version of patches is that voltage level for L2 and L3 loads is not increased, so power consumption for 200 and 250 MHz frequency should not be changed. Only for L1 load (500 MHz) is increased to 1108 mV. Could you test ondemand governor with these new patches? > I'm using schedutil, which had the very same issue. It never actually > switched to 1000mhz. It claimed it did, but the `mhz` util as well as the 7z > benchmark proved it never used anything >800mhz. > > Before: > $ 7z b > > 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 > > p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs > LE) > > LE > CPU Freq: 793 793 794 793 794 792 793 794 > > > RAM size: 985 MB, # CPU hardware threads: 2 > > RAM usage: 441 MB, # Benchmark threads: 2 > > > Compressing | Decompressing > > Dict Speed Usage R/U Rating | Speed Usage R/U Rating > > KiB/s % MIPS MIPS | KiB/s % MIPS MIPS > > > 22: 711 149 464 692 | 17501 194 770 1494 > > 23: 708 155 465 722 | 17595 198 770 1523 > > 24: 682 158 464 734 | 17079 196 764 1499 > > 25: 663 160 473 757 | 15595 189 734 1388 > ---------------------------------- | ------------------------------ > Avr: 156 466 726 | 194 760 1476 > Tot: 175 613 1101 > > > After: > $ 7z b > > 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 > p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs > LE) > > LE > CPU Freq: 992 998 998 994 996 997 997 997 > > RAM size: 987 MB, # CPU hardware threads: 2 > RAM usage: 441 MB, # Benchmark threads: 2 > > Compressing | Decompressing > Dict Speed Usage R/U Rating | Speed Usage R/U Rating > KiB/s % MIPS MIPS | KiB/s % MIPS MIPS > > 22: 866 151 559 843 | 22334 198 962 1907 > 23: 872 152 584 889 | 21809 197 959 1888 > 24: 808 145 599 869 | 11413 110 915 1002 > 25: 716 137 596 819 | 21092 198 949 1877 > ---------------------------------- | ------------------------------ > Avr: 146 585 855 | 176 946 1669 > Tot: 161 765 1262 > > > The measured frequency as well as the performance data finally looks good, > so: > > Tested-by: Andre Heider <a.heider@gmail.com> > > Thanks, > Andre _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-10-26 14:56 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-10-09 10:57 Armada 3720 cpufreq bug: request for testing (EspressoBIN, uDPU, ...) Marek Behún 2020-10-12 5:19 ` Andre Heider 2020-10-26 14:54 ` Pali Rohár
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.