Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
Tested-by: Philip Soares On Mon, Feb 22, 2021, at 8:36 AM, nnet wrote: > > Could I add your Tested-by line to patch series? > > Yes, by: Philip Soares > > Thank you for the patches! >
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
> Could I add your Tested-by line to patch series? Yes, by: Philip Soares Thank you for the patches!
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Sunday 21 February 2021 19:17:40 nnet wrote:
> > Could you test if 1.155V voltage for L1 is stable on 1.2 GHz variant?
>
> ++#define MIN_VOLT_MV_FOR_L1_1200MHZ 1155
> ...
> ++ if (avs_min_l1 > dvfs->avs[0])
> ++ avs_min_l1 = dvfs->avs[0];
> ++
> ++ if (dvfs->avs[1] < avs_min_l1)
> ++ dvfs->avs[1] = avs_min_l1;
>
> This works fine. Tested with switching 600MHz to 1.2GHz under load.
Perfect! Therefore here is final version of patch 04/10 for both 1 GHz
and 1.2 GHz variants of A3720 SoC. I will resend whole patch series.
Could I add your Tested-by line to patch series?
diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c
b/drivers/cpufreq/armada-37xx-cpufreq.c
index b8dc6c849..c7683d447 100644
--- a/drivers/cpufreq/armada-37xx-cpufreq.c
+++ b/drivers/cpufreq/armada-37xx-cpufreq.c
@@ -73,6 +73,8 @@
#define LOAD_LEVEL_NR 4
#define MIN_VOLT_MV 1000
+#define MIN_VOLT_MV_FOR_L1_1000MHZ 1108
+#define MIN_VOLT_MV_FOR_L1_1200MHZ 1155
/* AVS value for the corresponding voltage (in mV) */
static int avs_map[] = {
@@ -208,6 +210,8 @@ static u32 armada_37xx_avs_val_match(int target_vm)
* - L2 & L3 voltage should be about 150mv smaller than L0 voltage.
* This function calculates L1 & L2 & L3 AVS values dynamically based
* on L0 voltage and fill all AVS values to the AVS value table.
+ * When base CPU frequency is 1000 or 1200 MHz then there is additional
+ * minimal avs value for load L1.
*/
static void __init armada37xx_cpufreq_avs_configure(struct regmap *base,
struct armada_37xx_dvfs *dvfs)
@@ -239,6 +243,19 @@ static void __init armada37xx_cpufreq_avs_configure(struct
regmap *base,
for (load_level = 1; load_level < LOAD_LEVEL_NR; load_level++)
dvfs->avs[load_level] = avs_min;
+ /*
+* Set the avs values for load L0 and L1 when base CPU frequency
+* is 1000/1200 MHz to its typical initial values according to
+* the Armada 3700 Hardware Specifications.
+*/
+ if (dvfs->cpu_freq_max >= 1000*1000*1000) {
+ if (dvfs->cpu_freq_max >= 1200*1000*1000)
+ avs_min =
armada_37xx_avs_val_match(MIN_VOLT_MV_FOR_L1_1200MHZ);
+ else
+ avs_min =
armada_37xx_avs_val_match(MIN_VOLT_MV_FOR_L1_1000MHZ);
+ dvfs->avs[0] = dvfs->avs[1] = avs_min;
+ }
+
return;
}
@@ -258,6 +275,26 @@ static void __init armada37xx_cpufreq_avs_configure(struct
regmap *base,
target_vm = avs_map[l0_vdd_min] - 150;
target_vm = target_vm > MIN_VOLT_MV ? target_vm : MIN_VOLT_MV;
dvfs->avs[2] = dvfs->avs[3] = armada_37xx_avs_val_match(target_vm);
+
+ /*
+* Fix the avs value for load L1 when base CPU frequency is 1000/1200
MHz,
+* otherwise the CPU gets stuck when switching from load L1 to load L0.
+* Also ensure that avs value for load L1 is not higher than for L0.
+*/
+ if (dvfs->cpu_freq_max >= 1000*1000*1000) {
+ u32 avs_min_l1;
+
+ if (dvfs->cpu_freq_max >= 1200*1000*1000)
+ avs_min_l1 =
armada_37xx_avs_val_match(MIN_VOLT_MV_FOR_L1_1200MHZ);
+ else
+ avs_min_l1 =
armada_37xx_avs_val_match(MIN_VOLT_MV_FOR_L1_1000MHZ);
+
+ if (avs_min_l1 > dvfs->avs[0])
+ avs_min_l1 = dvfs->avs[0];
+
+ if (dvfs->avs[1] < avs_min_l1)
+ dvfs->avs[1] = avs_min_l1;
+ }
}
static void __init armada37xx_cpufreq_avs_setup(struct regmap *base,
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
> Could you test if 1.155V voltage for L1 is stable on 1.2 GHz variant? ++#define MIN_VOLT_MV_FOR_L1_1200MHZ 1155 ... ++ if (avs_min_l1 > dvfs->avs[0]) ++ avs_min_l1 = dvfs->avs[0]; ++ ++ if (dvfs->avs[1] < avs_min_l1) ++ dvfs->avs[1] = avs_min_l1; This works fine. Tested with switching 600MHz to 1.2GHz under load.
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tuesday 16 February 2021 08:27:10 nnet wrote: > > Therefore I'm thinking if the correct way is instead to use L1 := L0 > > voltage value for 1/1.2 GHz mode. > > This latest 04/10 works fine for me going 600MHz <-> 1.2GHz under with and > without load. Ok, thanks for testing! Just to note that typical documented value for 1.2GHz mode is 1.155V, so it would be useful to know if this value could be stable for L1 with 1.2GHz mode. I'm thinking that for 1GHz variant it would be better to rather use 1.108V like in my original patch as this is already tested by lot of people, nobody complained yet and it can be lower value as L0 (so there is benefit to decrease CPU frequency when CPU is idle). For 1.2GHz variant I still do not know. You wrote that 1.132V is unstable, so it cannot be used for sure. Documented typical value 1.155V is bigger, so maybe it can be stable but needs testing. And stable seems to be L0 value... But then I do not see a benefit for downclocking CPU from 1.2 GHz frequency in L0 to 600 MHz freq. in L1 if it use same CPU voltage... But it is still better than unstable CPU with crashes! Could you test if 1.155V voltage for L1 is stable on 1.2 GHz variant?
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
> Therefore I'm thinking if the correct way is instead to use L1 := L0 voltage > value for 1/1.2 GHz mode. This latest 04/10 works fine for me going 600MHz <-> 1.2GHz under with and without load.
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Monday 15 February 2021 21:48:08 nnet wrote:
> > Could you test following change instead of PATCH 04/10? I added here also
> > logic for 1.2 GHz variant with 1.132 V value another change is that
> > value for load L0 is not touched as it is stable.
>
> These changes to patch 04/10 worked going 600 MHz <-> 1.2 GHz , _but_ only
> with:
>
> ++#define MIN_VOLT_MV_FOR_L1_1200MHZ 1213
>
> During this latest testing I saw freezes with 1132 mV.
>
> I've had no lockups with 1213 mV which I just used from the values for L1/L0
> from OTP.
I still do not know what is the meaning of values stored in OTP...
And there are more non-zero bits which are not used (yet).
Anyway, with your another test it looks like that limit is not based on
fixed value but rather on current L0 value. Therefore I'm thinking if
the correct way is instead to use L1 := L0 voltage value for 1/1.2 GHz
mode. Could you try following change instead of previous and PATCH 04/10?
diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c
b/drivers/cpufreq/armada-37xx-cpufreq.c
index b8dc6c849..12d0ff7b1 100644
--- a/drivers/cpufreq/armada-37xx-cpufreq.c
+++ b/drivers/cpufreq/armada-37xx-cpufreq.c
@@ -208,6 +208,8 @@ static u32 armada_37xx_avs_val_match(int target_vm)
* - L2 & L3 voltage should be about 150mv smaller than L0 voltage.
* This function calculates L1 & L2 & L3 AVS values dynamically based
* on L0 voltage and fill all AVS values to the AVS value table.
+ * When base CPU frequency is 1000 or 1200 MHz then there is additional
+ * minimal avs value for load L1.
*/
static void __init armada37xx_cpufreq_avs_configure(struct regmap *base,
struct armada_37xx_dvfs *dvfs)
@@ -239,17 +241,36 @@ static void __init
armada37xx_cpufreq_avs_configure(struct regmap *base,
for (load_level = 1; load_level < LOAD_LEVEL_NR; load_level++)
dvfs->avs[load_level] = avs_min;
+ /*
+* Set the avs values for load L0 and L1 when base CPU frequency
+* is 1000/1200 MHz to its typical initial values according to
+* the Armada 3700 Hardware Specifications.
+*/
+ if (dvfs->cpu_freq_max >= 1000*1000*1000) {
+ if (dvfs->cpu_freq_max >= 1200*1000*1000)
+ avs_min = armada_37xx_avs_val_match(1155);
+ else
+ avs_min = armada_37xx_avs_val_match(1108);
+ dvfs->avs[0] = dvfs->avs[1] = avs_min;
+ }
+
return;
}
/*
* L1 voltage is equal to L0 voltage - 100mv and it must be
-* larger than 1000mv
+* larger than 1000mv. When base CPU frequency is 1000/1200 MHz,
+* L1 voltage must must be equal to L0 voltage, otherwise
+* the CPU gets stuck when switching from load L1 to load L0.
*/
- target_vm = avs_map[l0_vdd_min] - 100;
- target_vm = target_vm > MIN_VOLT_MV ? target_vm : MIN_VOLT_MV;
- dvfs->avs[1] = armada_37xx_avs_val_match(target_vm);
+ if (dvfs->cpu_freq_max >= 1000*1000*1000) {
+ dvfs->avs[1] = dvfs->avs[0];
+ } else {
+ target_vm = avs_map[l0_vdd_min] - 100;
+ target_vm = target_vm > MIN_VOLT_MV ? target_vm : MIN_VOLT_MV;
+ dvfs->avs[1] = armada_37xx_avs_val_match(target_vm);
+ }
/*
* L2 & L3 voltage is equal to L0 voltage - 150mv and it must
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
> Could you test following change instead of PATCH 04/10? I added here also > logic for 1.2 GHz variant with 1.132 V value another change is that > value for load L0 is not touched as it is stable. These changes to patch 04/10 worked going 600 MHz <-> 1.2 GHz , _but_ only with: ++#define MIN_VOLT_MV_FOR_L1_1200MHZ 1213 During this latest testing I saw freezes with 1132 mV. I've had no lockups with 1213 mV which I just used from the values for L1/L0 from OTP. I only tested with those two values.
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Saturday 13 February 2021 10:30:19 nnet wrote: > On Sat, Feb 13, 2021, at 2:01 AM, Pali Rohár wrote: > > On Thursday 11 February 2021 16:41:13 nnet wrote: > > > On Thu, Feb 11, 2021, at 3:44 PM, Pali Rohár wrote: > > > > On Thursday 11 February 2021 12:22:52 nnet wrote: > > > > > On Thu, Feb 11, 2021, at 11:55 AM, Pali Rohár wrote: > > > > > > On Wednesday 10 February 2021 11:08:59 nnet wrote: > > > > > > > On Wed, Feb 10, 2021, at 10:03 AM, Pali Rohár wrote: > > > > > > > > > > Hello! Could you please enable userspace governor during > > > > > > > > > > kernel > > > > > > > > > > compilation? > > > > > > > > > > > > > > > > > > > > CONFIG_CPU_FREQ_GOV_USERSPACE=y > > > > > > > > > > > > > > > > > > > > It can be activated via command: > > > > > > > > > > > > > > > > > > > > echo userspace > > > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > > > > > > > > > > > > > > > After that you can "force" CPU frequency to specific value, > > > > > > > > > > e.g.: > > > > > > > > > > > > > > > > > > > > echo 100 > > > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed > > > > > > > > > > > > > > > > > > > > I need to know which switch (from --> to freq) cause this > > > > > > > > > > system hang. > > > > > > > > > > > > > > > > > > > > This patch series (via MIN_VOLT_MV_FOR_L0_L1_1GHZ) is > > > > > > > > > > fixing only > > > > > > > > > > switching from 500 MHz to 1000 MHz on 1 GHz variant. As > > > > > > > > > > only this switch > > > > > > > > > > is causing issue. > > > > > > > > > > > > > > > > > > > > I have used following simple bash script to check that > > > > > > > > > > switching between > > > > > > > > > > 500 MHz and 1 GHz is stable: > > > > > > > > > > > > > > > > > > > > while true; do > > > > > > > > > > echo 100 > > > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > > > echo 50 > > > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > > > echo 100 > > > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > > > echo 50 > > > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > > > done > > > > > > > > > > > > > > > > > > echo userspace | tee > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > > > > while true; do > > > > > > > > > echo 120 | tee > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > > echo 60 | tee > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > > done > > > > > > > > > > > > > > > > > > >> +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 > > > > > > > > > > > > > > > > > > With 1108 I get a freeze within a minute. The last output to > > > > > > > > > stdout is 60. > > > > > > > > > > > > > > > > > > With 1120 it takes a few minutes. > > > > > > > > > > > > > > > > > > With any of 1225, 1155, 1132 the device doesn't freeze over > > > > > > > > > the full 5 minute load test. > > > > > > > > > > > > > > > > > > I'm using ondemand now with the above at 1132 without issue > > > > > > > > > so far. > > > > > > > > > > > > > > > > Great, thank you for testing! > > > > > > > > > > > > > > > > Can you check if switching between any two lower frequencies > > > > > > > > 20 > > > > > > > > 30 60 is stable? > > > > > > > > > > > > > > This is stable using 1132 mV for MIN_VOLT_MV_FOR_L0_L1_1GHZ: > > > > > > > > > > > > > > while true; do > > > > > > > # down > > > > > > > echo 120 | tee > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > ... > > > > > > > > > > > > Hello! > > > > > > > > > > > > Could you please re-run test without tee, in form as I have shown > > > > > > above? > > > > > > UART is slow and printing something to console adds delay which > > > > > > decrease > > > > > > probability that real issue is triggered as this is timing issue. > > > > > > > > > > The test was done over SSH. > > > > > > > > Ok! But it is still better to not print any results as it adds unwanted > > > > delay between frequency switching. > > > > > > > > > > Also please do tests just between two frequencies in loop as I > > > > > > observed > > > > > > that switching between more decreased probability to hit issue. > > > > > > > > > > > > > > echo userspace | tee > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > > > > while true; do > > > > > > > > > echo 120 | tee > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > > echo 60 | tee > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > > done > > > > > > > > > > The first test ^ switched between 600 MHz and 1.2 GHz. > > > > > >
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Sat, Feb 13, 2021, at 2:01 AM, Pali Rohár wrote: > On Thursday 11 February 2021 16:41:13 nnet wrote: > > On Thu, Feb 11, 2021, at 3:44 PM, Pali Rohár wrote: > > > On Thursday 11 February 2021 12:22:52 nnet wrote: > > > > On Thu, Feb 11, 2021, at 11:55 AM, Pali Rohár wrote: > > > > > On Wednesday 10 February 2021 11:08:59 nnet wrote: > > > > > > On Wed, Feb 10, 2021, at 10:03 AM, Pali Rohár wrote: > > > > > > > > > Hello! Could you please enable userspace governor during > > > > > > > > > kernel > > > > > > > > > compilation? > > > > > > > > > > > > > > > > > > CONFIG_CPU_FREQ_GOV_USERSPACE=y > > > > > > > > > > > > > > > > > > It can be activated via command: > > > > > > > > > > > > > > > > > > echo userspace > > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > > > > > > > > > > > > > After that you can "force" CPU frequency to specific value, > > > > > > > > > e.g.: > > > > > > > > > > > > > > > > > > echo 100 > > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed > > > > > > > > > > > > > > > > > > I need to know which switch (from --> to freq) cause this > > > > > > > > > system hang. > > > > > > > > > > > > > > > > > > This patch series (via MIN_VOLT_MV_FOR_L0_L1_1GHZ) is fixing > > > > > > > > > only > > > > > > > > > switching from 500 MHz to 1000 MHz on 1 GHz variant. As only > > > > > > > > > this switch > > > > > > > > > is causing issue. > > > > > > > > > > > > > > > > > > I have used following simple bash script to check that > > > > > > > > > switching between > > > > > > > > > 500 MHz and 1 GHz is stable: > > > > > > > > > > > > > > > > > > while true; do > > > > > > > > > echo 100 > > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > > echo 50 > > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > > echo 100 > > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > > echo 50 > > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > > done > > > > > > > > > > > > > > > > echo userspace | tee > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > > > while true; do > > > > > > > > echo 120 | tee > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > echo 60 | tee > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > done > > > > > > > > > > > > > > > > >> +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 > > > > > > > > > > > > > > > > With 1108 I get a freeze within a minute. The last output to > > > > > > > > stdout is 60. > > > > > > > > > > > > > > > > With 1120 it takes a few minutes. > > > > > > > > > > > > > > > > With any of 1225, 1155, 1132 the device doesn't freeze over the > > > > > > > > full 5 minute load test. > > > > > > > > > > > > > > > > I'm using ondemand now with the above at 1132 without issue so > > > > > > > > far. > > > > > > > > > > > > > > Great, thank you for testing! > > > > > > > > > > > > > > Can you check if switching between any two lower frequencies > > > > > > > 20 > > > > > > > 30 60 is stable? > > > > > > > > > > > > This is stable using 1132 mV for MIN_VOLT_MV_FOR_L0_L1_1GHZ: > > > > > > > > > > > > while true; do > > > > > > # down > > > > > > echo 120 | tee > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > ... > > > > > > > > > > Hello! > > > > > > > > > > Could you please re-run test without tee, in form as I have shown > > > > > above? > > > > > UART is slow and printing something to console adds delay which > > > > > decrease > > > > > probability that real issue is triggered as this is timing issue. > > > > > > > > The test was done over SSH. > > > > > > Ok! But it is still better to not print any results as it adds unwanted > > > delay between frequency switching. > > > > > > > > Also please do tests just between two frequencies in loop as I > > > > > observed > > > > > that switching between more decreased probability to hit issue. > > > > > > > > > > > > echo userspace | tee > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > > > while true; do > > > > > > > > echo 120 | tee > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > echo 60 | tee > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > done > > > > > > > > The first test ^ switched between 600 MHz and 1.2 GHz. > > > > > > > > > The real issue for 1 GHz variant of A3720 is only when doing switch > > > > > from > > > > > 500 MHz to 1 GHz. So could you try to do some tests also without > > > > > changing MIN_VOLT_MV_FOR_L0_L1_1GHZ and switching just between non-1.2 > > > > > frequencies
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Thursday 11 February 2021 16:41:13 nnet wrote: > On Thu, Feb 11, 2021, at 3:44 PM, Pali Rohár wrote: > > On Thursday 11 February 2021 12:22:52 nnet wrote: > > > On Thu, Feb 11, 2021, at 11:55 AM, Pali Rohár wrote: > > > > On Wednesday 10 February 2021 11:08:59 nnet wrote: > > > > > On Wed, Feb 10, 2021, at 10:03 AM, Pali Rohár wrote: > > > > > > > > Hello! Could you please enable userspace governor during kernel > > > > > > > > compilation? > > > > > > > > > > > > > > > > CONFIG_CPU_FREQ_GOV_USERSPACE=y > > > > > > > > > > > > > > > > It can be activated via command: > > > > > > > > > > > > > > > > echo userspace > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > > > > > > > > > > > After that you can "force" CPU frequency to specific value, > > > > > > > > e.g.: > > > > > > > > > > > > > > > > echo 100 > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed > > > > > > > > > > > > > > > > I need to know which switch (from --> to freq) cause this > > > > > > > > system hang. > > > > > > > > > > > > > > > > This patch series (via MIN_VOLT_MV_FOR_L0_L1_1GHZ) is fixing > > > > > > > > only > > > > > > > > switching from 500 MHz to 1000 MHz on 1 GHz variant. As only > > > > > > > > this switch > > > > > > > > is causing issue. > > > > > > > > > > > > > > > > I have used following simple bash script to check that > > > > > > > > switching between > > > > > > > > 500 MHz and 1 GHz is stable: > > > > > > > > > > > > > > > > while true; do > > > > > > > > echo 100 > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > echo 50 > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > echo 100 > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > echo 50 > > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > > done > > > > > > > > > > > > > > echo userspace | tee > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > > while true; do > > > > > > > echo 120 | tee > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > echo 60 | tee > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > done > > > > > > > > > > > > > > >> +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 > > > > > > > > > > > > > > With 1108 I get a freeze within a minute. The last output to > > > > > > > stdout is 60. > > > > > > > > > > > > > > With 1120 it takes a few minutes. > > > > > > > > > > > > > > With any of 1225, 1155, 1132 the device doesn't freeze over the > > > > > > > full 5 minute load test. > > > > > > > > > > > > > > I'm using ondemand now with the above at 1132 without issue so > > > > > > > far. > > > > > > > > > > > > Great, thank you for testing! > > > > > > > > > > > > Can you check if switching between any two lower frequencies 20 > > > > > > 30 60 is stable? > > > > > > > > > > This is stable using 1132 mV for MIN_VOLT_MV_FOR_L0_L1_1GHZ: > > > > > > > > > > while true; do > > > > > # down > > > > > echo 120 | tee > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > ... > > > > > > > > Hello! > > > > > > > > Could you please re-run test without tee, in form as I have shown above? > > > > UART is slow and printing something to console adds delay which decrease > > > > probability that real issue is triggered as this is timing issue. > > > > > > The test was done over SSH. > > > > Ok! But it is still better to not print any results as it adds unwanted > > delay between frequency switching. > > > > > > Also please do tests just between two frequencies in loop as I observed > > > > that switching between more decreased probability to hit issue. > > > > > > > > > > echo userspace | tee > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > > while true; do > > > > > > > echo 120 | tee > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > echo 60 | tee > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > done > > > > > > The first test ^ switched between 600 MHz and 1.2 GHz. > > > > > > > The real issue for 1 GHz variant of A3720 is only when doing switch from > > > > 500 MHz to 1 GHz. So could you try to do some tests also without > > > > changing MIN_VOLT_MV_FOR_L0_L1_1GHZ and switching just between non-1.2 > > > > frequencies (to verify that on 1.2 GHz variant it is also from 600 MHz > > > > to 1.2 GHz)? > > > > > > With 1108 mV and switching between 600 MHz and 1.2GHz, I always saw a > > > freeze within a minute. > > > > I mean to try switching with 1.108 V between 200 MHz and 300 MHz or > > between 300 MHz and 600 MHz. To check that issue is really only with > > switch
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Thu, Feb 11, 2021, at 3:44 PM, Pali Rohár wrote: > On Thursday 11 February 2021 12:22:52 nnet wrote: > > On Thu, Feb 11, 2021, at 11:55 AM, Pali Rohár wrote: > > > On Wednesday 10 February 2021 11:08:59 nnet wrote: > > > > On Wed, Feb 10, 2021, at 10:03 AM, Pali Rohár wrote: > > > > > > > Hello! Could you please enable userspace governor during kernel > > > > > > > compilation? > > > > > > > > > > > > > > CONFIG_CPU_FREQ_GOV_USERSPACE=y > > > > > > > > > > > > > > It can be activated via command: > > > > > > > > > > > > > > echo userspace > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > > > > > > > > > After that you can "force" CPU frequency to specific value, e.g.: > > > > > > > > > > > > > > echo 100 > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed > > > > > > > > > > > > > > I need to know which switch (from --> to freq) cause this system > > > > > > > hang. > > > > > > > > > > > > > > This patch series (via MIN_VOLT_MV_FOR_L0_L1_1GHZ) is fixing only > > > > > > > switching from 500 MHz to 1000 MHz on 1 GHz variant. As only this > > > > > > > switch > > > > > > > is causing issue. > > > > > > > > > > > > > > I have used following simple bash script to check that switching > > > > > > > between > > > > > > > 500 MHz and 1 GHz is stable: > > > > > > > > > > > > > > while true; do > > > > > > > echo 100 > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > echo 50 > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > echo 100 > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > echo 50 > > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > > done > > > > > > > > > > > > echo userspace | tee > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > while true; do > > > > > > echo 120 | tee > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > echo 60 | tee > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > done > > > > > > > > > > > > >> +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 > > > > > > > > > > > > With 1108 I get a freeze within a minute. The last output to stdout > > > > > > is 60. > > > > > > > > > > > > With 1120 it takes a few minutes. > > > > > > > > > > > > With any of 1225, 1155, 1132 the device doesn't freeze over the > > > > > > full 5 minute load test. > > > > > > > > > > > > I'm using ondemand now with the above at 1132 without issue so far. > > > > > > > > > > Great, thank you for testing! > > > > > > > > > > Can you check if switching between any two lower frequencies 20 > > > > > 30 60 is stable? > > > > > > > > This is stable using 1132 mV for MIN_VOLT_MV_FOR_L0_L1_1GHZ: > > > > > > > > while true; do > > > > # down > > > > echo 120 | tee > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > ... > > > > > > Hello! > > > > > > Could you please re-run test without tee, in form as I have shown above? > > > UART is slow and printing something to console adds delay which decrease > > > probability that real issue is triggered as this is timing issue. > > > > The test was done over SSH. > > Ok! But it is still better to not print any results as it adds unwanted > delay between frequency switching. > > > > Also please do tests just between two frequencies in loop as I observed > > > that switching between more decreased probability to hit issue. > > > > > > > > echo userspace | tee > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > while true; do > > > > > > echo 120 | tee > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > echo 60 | tee > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > done > > > > The first test ^ switched between 600 MHz and 1.2 GHz. > > > > > The real issue for 1 GHz variant of A3720 is only when doing switch from > > > 500 MHz to 1 GHz. So could you try to do some tests also without > > > changing MIN_VOLT_MV_FOR_L0_L1_1GHZ and switching just between non-1.2 > > > frequencies (to verify that on 1.2 GHz variant it is also from 600 MHz > > > to 1.2 GHz)? > > > > With 1108 mV and switching between 600 MHz and 1.2GHz, I always saw a > > freeze within a minute. > > I mean to try switching with 1.108 V between 200 MHz and 300 MHz or > between 300 MHz and 600 MHz. To check that issue is really only with > switch from 600 MHz to 1.2 GHz. With: +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 with 5 min load: # no lock-up echo userspace > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor while true; do echo 20 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; echo 30 >
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Thursday 11 February 2021 12:22:52 nnet wrote: > On Thu, Feb 11, 2021, at 11:55 AM, Pali Rohár wrote: > > On Wednesday 10 February 2021 11:08:59 nnet wrote: > > > On Wed, Feb 10, 2021, at 10:03 AM, Pali Rohár wrote: > > > > > > Hello! Could you please enable userspace governor during kernel > > > > > > compilation? > > > > > > > > > > > > CONFIG_CPU_FREQ_GOV_USERSPACE=y > > > > > > > > > > > > It can be activated via command: > > > > > > > > > > > > echo userspace > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > > > > > > > After that you can "force" CPU frequency to specific value, e.g.: > > > > > > > > > > > > echo 100 > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed > > > > > > > > > > > > I need to know which switch (from --> to freq) cause this system > > > > > > hang. > > > > > > > > > > > > This patch series (via MIN_VOLT_MV_FOR_L0_L1_1GHZ) is fixing only > > > > > > switching from 500 MHz to 1000 MHz on 1 GHz variant. As only this > > > > > > switch > > > > > > is causing issue. > > > > > > > > > > > > I have used following simple bash script to check that switching > > > > > > between > > > > > > 500 MHz and 1 GHz is stable: > > > > > > > > > > > > while true; do > > > > > > echo 100 > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > echo 50 > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > echo 100 > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > echo 50 > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > > done > > > > > > > > > > echo userspace | tee > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > while true; do > > > > > echo 120 | tee > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > echo 60 | tee > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > done > > > > > > > > > > >> +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 > > > > > > > > > > With 1108 I get a freeze within a minute. The last output to stdout > > > > > is 60. > > > > > > > > > > With 1120 it takes a few minutes. > > > > > > > > > > With any of 1225, 1155, 1132 the device doesn't freeze over the full > > > > > 5 minute load test. > > > > > > > > > > I'm using ondemand now with the above at 1132 without issue so far. > > > > > > > > Great, thank you for testing! > > > > > > > > Can you check if switching between any two lower frequencies 20 > > > > 30 60 is stable? > > > > > > This is stable using 1132 mV for MIN_VOLT_MV_FOR_L0_L1_1GHZ: > > > > > > while true; do > > > # down > > > echo 120 | tee > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > ... > > > > Hello! > > > > Could you please re-run test without tee, in form as I have shown above? > > UART is slow and printing something to console adds delay which decrease > > probability that real issue is triggered as this is timing issue. > > The test was done over SSH. Ok! But it is still better to not print any results as it adds unwanted delay between frequency switching. > > Also please do tests just between two frequencies in loop as I observed > > that switching between more decreased probability to hit issue. > > > > > > echo userspace | tee > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > while true; do > > > > > echo 120 | tee > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > echo 60 | tee > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > done > > The first test ^ switched between 600 MHz and 1.2 GHz. > > > The real issue for 1 GHz variant of A3720 is only when doing switch from > > 500 MHz to 1 GHz. So could you try to do some tests also without > > changing MIN_VOLT_MV_FOR_L0_L1_1GHZ and switching just between non-1.2 > > frequencies (to verify that on 1.2 GHz variant it is also from 600 MHz > > to 1.2 GHz)? > > With 1108 mV and switching between 600 MHz and 1.2GHz, I always saw a freeze > within a minute. I mean to try switching with 1.108 V between 200 MHz and 300 MHz or between 300 MHz and 600 MHz. To check that issue is really only with switch from 600 MHz to 1.2 GHz. I need to know if current settings are fine for 200, 300 and 600 MHz frequencies and the only 600 --> 1200 needs to be fixed.
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Thu, Feb 11, 2021, at 11:55 AM, Pali Rohár wrote: > On Wednesday 10 February 2021 11:08:59 nnet wrote: > > On Wed, Feb 10, 2021, at 10:03 AM, Pali Rohár wrote: > > > > > Hello! Could you please enable userspace governor during kernel > > > > > compilation? > > > > > > > > > > CONFIG_CPU_FREQ_GOV_USERSPACE=y > > > > > > > > > > It can be activated via command: > > > > > > > > > > echo userspace > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > > > > > After that you can "force" CPU frequency to specific value, e.g.: > > > > > > > > > > echo 100 > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed > > > > > > > > > > I need to know which switch (from --> to freq) cause this system hang. > > > > > > > > > > This patch series (via MIN_VOLT_MV_FOR_L0_L1_1GHZ) is fixing only > > > > > switching from 500 MHz to 1000 MHz on 1 GHz variant. As only this > > > > > switch > > > > > is causing issue. > > > > > > > > > > I have used following simple bash script to check that switching > > > > > between > > > > > 500 MHz and 1 GHz is stable: > > > > > > > > > > while true; do > > > > > echo 100 > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > echo 50 > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > echo 100 > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > echo 50 > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > > done > > > > > > > > echo userspace | tee > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > while true; do > > > > echo 120 | tee > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > echo 60 | tee > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > done > > > > > > > > >> +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 > > > > > > > > With 1108 I get a freeze within a minute. The last output to stdout is > > > > 60. > > > > > > > > With 1120 it takes a few minutes. > > > > > > > > With any of 1225, 1155, 1132 the device doesn't freeze over the full 5 > > > > minute load test. > > > > > > > > I'm using ondemand now with the above at 1132 without issue so far. > > > > > > Great, thank you for testing! > > > > > > Can you check if switching between any two lower frequencies 20 > > > 30 60 is stable? > > > > This is stable using 1132 mV for MIN_VOLT_MV_FOR_L0_L1_1GHZ: > > > > while true; do > > # down > > echo 120 | tee > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > ... > > Hello! > > Could you please re-run test without tee, in form as I have shown above? > UART is slow and printing something to console adds delay which decrease > probability that real issue is triggered as this is timing issue. The test was done over SSH. > Also please do tests just between two frequencies in loop as I observed > that switching between more decreased probability to hit issue. > > > > echo userspace | tee > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > while true; do > > > > echo 120 | tee > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > echo 60 | tee > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > done The first test ^ switched between 600 MHz and 1.2 GHz. > The real issue for 1 GHz variant of A3720 is only when doing switch from > 500 MHz to 1 GHz. So could you try to do some tests also without > changing MIN_VOLT_MV_FOR_L0_L1_1GHZ and switching just between non-1.2 > frequencies (to verify that on 1.2 GHz variant it is also from 600 MHz > to 1.2 GHz)? With 1108 mV and switching between 600 MHz and 1.2GHz, I always saw a freeze within a minute.
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Wednesday 10 February 2021 11:08:59 nnet wrote: > On Wed, Feb 10, 2021, at 10:03 AM, Pali Rohár wrote: > > > > Hello! Could you please enable userspace governor during kernel > > > > compilation? > > > > > > > > CONFIG_CPU_FREQ_GOV_USERSPACE=y > > > > > > > > It can be activated via command: > > > > > > > > echo userspace > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > > > After that you can "force" CPU frequency to specific value, e.g.: > > > > > > > > echo 100 > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed > > > > > > > > I need to know which switch (from --> to freq) cause this system hang. > > > > > > > > This patch series (via MIN_VOLT_MV_FOR_L0_L1_1GHZ) is fixing only > > > > switching from 500 MHz to 1000 MHz on 1 GHz variant. As only this switch > > > > is causing issue. > > > > > > > > I have used following simple bash script to check that switching between > > > > 500 MHz and 1 GHz is stable: > > > > > > > > while true; do > > > > echo 100 > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > echo 50 > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > echo 100 > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > echo 50 > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > > done > > > > > > echo userspace | tee > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > while true; do > > > echo 120 | tee > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > echo 60 | tee > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > done > > > > > > >> +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 > > > > > > With 1108 I get a freeze within a minute. The last output to stdout is > > > 60. > > > > > > With 1120 it takes a few minutes. > > > > > > With any of 1225, 1155, 1132 the device doesn't freeze over the full 5 > > > minute load test. > > > > > > I'm using ondemand now with the above at 1132 without issue so far. > > > > Great, thank you for testing! > > > > Can you check if switching between any two lower frequencies 20 > > 30 60 is stable? > > This is stable using 1132 mV for MIN_VOLT_MV_FOR_L0_L1_1GHZ: > > while true; do > # down > echo 120 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; ... Hello! Could you please re-run test without tee, in form as I have shown above? UART is slow and printing something to console adds delay which decrease probability that real issue is triggered as this is timing issue. Also please do tests just between two frequencies in loop as I observed that switching between more decreased probability to hit issue. The real issue for 1 GHz variant of A3720 is only when doing switch from 500 MHz to 1 GHz. So could you try to do some tests also without changing MIN_VOLT_MV_FOR_L0_L1_1GHZ and switching just between non-1.2 frequencies (to verify that on 1.2 GHz variant it is also from 600 MHz to 1.2 GHz)?
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Wed, 10 Feb 2021 11:08:59 -0800 nnet wrote: > => md d0012604 1; md d0012604 1; md d0012604 1 > d0012604: 2b417501 .uA+ > d0012604: 945b [... > d0012604: So this means that in OTP you have this values: 1200 MHz - 1213 mV 1000 MHz - 1213 mV 800 MHz - 1097 mV 600 MHz - 898 mV
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Wed, Feb 10, 2021, at 10:03 AM, Pali Rohár wrote: > On Wednesday 10 February 2021 09:34:07 nnet wrote: > > On Wed, Feb 10, 2021, at 1:23 AM, Pali Rohár wrote: > > > On Tuesday 09 February 2021 18:07:41 nnet wrote: > > > > On Tue, Feb 9, 2021, at 5:51 PM, nnet wrote: > > > > > On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote: > > > > > > On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote: > > > > > > > On Tue, 09 Feb 2021 15:16:45 -0800 > > > > > > > nnet wrote: > > > > > > > > > > > > > > > I've two of these and I've just swapped them (and re-pasted the > > > > > > > > heat sinks). > > > > > > > > > > > > > > > > The second one ran under load for awhile and now has frozen as > > > > > > > > well. > > > > > > > > > > > > > > > > Under a moderate load `wget -O /dev/null ` @X00Mbits > > > > > > > > they are fine. > > > > > > > > > > > > > > > > Under a 1 min speed test of load ~200Mbits routed WireGuard > > > > > > > > they freeze. > > > > > > > > > > > > > > > > They fine with both those workloads @1000_800. > > > > > > > > > > > > > > > > Perhaps it's heat? Unfortunately I don't have any numbers on > > > > > > > > that ATM. > > > > > > > > > > > > > > Try disabling cpufreq in kernel completely, compile boot image at > > > > > > > 1200 MHz. If it continues freezing, then I fear we can't help you > > > > > > > with > > > > > > > 1200 MHz :( > > > > > > > > > > > > cat > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies > > > > > > > > > > > > 20 30 60 120 > > > > > > > > > > > > I'm not getting any freezes with 1.2GHz fixed after 20 minutes of > > > > > > load: > > > > > > > > > > > > echo 120 > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq > > > > > > > > > > > > Setting it back to min 200MHz I get a freeze within a minute: > > > > > > > > > > > > echo 20 > > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq > > > > > > Hello! Could you please enable userspace governor during kernel > > > compilation? > > > > > > CONFIG_CPU_FREQ_GOV_USERSPACE=y > > > > > > It can be activated via command: > > > > > > echo userspace > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > > > After that you can "force" CPU frequency to specific value, e.g.: > > > > > > echo 100 > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed > > > > > > I need to know which switch (from --> to freq) cause this system hang. > > > > > > This patch series (via MIN_VOLT_MV_FOR_L0_L1_1GHZ) is fixing only > > > switching from 500 MHz to 1000 MHz on 1 GHz variant. As only this switch > > > is causing issue. > > > > > > I have used following simple bash script to check that switching between > > > 500 MHz and 1 GHz is stable: > > > > > > while true; do > > > echo 100 > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > echo 50 > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > echo 100 > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > echo 50 > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > > done > > > > echo userspace | tee > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > while true; do > > echo 120 | tee > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > echo 60 | tee > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > done > > > > >> +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 > > > > With 1108 I get a freeze within a minute. The last output to stdout is > > 60. > > > > With 1120 it takes a few minutes. > > > > With any of 1225, 1155, 1132 the device doesn't freeze over the full 5 > > minute load test. > > > > I'm using ondemand now with the above at 1132 without issue so far. > > Great, thank you for testing! > > Can you check if switching between any two lower frequencies 20 > 30 60 is stable? This is stable using 1132 mV for MIN_VOLT_MV_FOR_L0_L1_1GHZ: while true; do # down echo 120 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; echo 60 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; echo 30 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; echo 20 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; # up echo 30 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; echo 60 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; echo 120 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; # all down echo 20 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; # all up echo 120 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; # almost down echo 30 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; done > > >> Update the CPU voltage value for
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Wednesday 10 February 2021 09:34:07 nnet wrote: > On Wed, Feb 10, 2021, at 1:23 AM, Pali Rohár wrote: > > On Tuesday 09 February 2021 18:07:41 nnet wrote: > > > On Tue, Feb 9, 2021, at 5:51 PM, nnet wrote: > > > > On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote: > > > > > On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote: > > > > > > On Tue, 09 Feb 2021 15:16:45 -0800 > > > > > > nnet wrote: > > > > > > > > > > > > > I've two of these and I've just swapped them (and re-pasted the > > > > > > > heat sinks). > > > > > > > > > > > > > > The second one ran under load for awhile and now has frozen as > > > > > > > well. > > > > > > > > > > > > > > Under a moderate load `wget -O /dev/null ` @X00Mbits > > > > > > > they are fine. > > > > > > > > > > > > > > Under a 1 min speed test of load ~200Mbits routed WireGuard they > > > > > > > freeze. > > > > > > > > > > > > > > They fine with both those workloads @1000_800. > > > > > > > > > > > > > > Perhaps it's heat? Unfortunately I don't have any numbers on that > > > > > > > ATM. > > > > > > > > > > > > Try disabling cpufreq in kernel completely, compile boot image at > > > > > > 1200 MHz. If it continues freezing, then I fear we can't help you > > > > > > with > > > > > > 1200 MHz :( > > > > > > > > > > cat > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies > > > > > 20 30 60 120 > > > > > > > > > > I'm not getting any freezes with 1.2GHz fixed after 20 minutes of > > > > > load: > > > > > > > > > > echo 120 > > > > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq > > > > > > > > > > Setting it back to min 200MHz I get a freeze within a minute: > > > > > > > > > > echo 20 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq > > > > Hello! Could you please enable userspace governor during kernel > > compilation? > > > > CONFIG_CPU_FREQ_GOV_USERSPACE=y > > > > It can be activated via command: > > > > echo userspace > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > > > > After that you can "force" CPU frequency to specific value, e.g.: > > > > echo 100 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed > > > > I need to know which switch (from --> to freq) cause this system hang. > > > > This patch series (via MIN_VOLT_MV_FOR_L0_L1_1GHZ) is fixing only > > switching from 500 MHz to 1000 MHz on 1 GHz variant. As only this switch > > is causing issue. > > > > I have used following simple bash script to check that switching between > > 500 MHz and 1 GHz is stable: > > > > while true; do > > echo 100 > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > echo 50 > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > echo 100 > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > echo 50 > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > > done > > echo userspace | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_governor > while true; do > echo 120 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > echo 60 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed; > done > > >> +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 > > With 1108 I get a freeze within a minute. The last output to stdout is 60. > > With 1120 it takes a few minutes. > > With any of 1225, 1155, 1132 the device doesn't freeze over the full 5 minute > load test. > > I'm using ondemand now with the above at 1132 without issue so far. Great, thank you for testing! Can you check if switching between any two lower frequencies 20 30 60 is stable? > >> Update the CPU voltage value for loads L0 and L1 accordingly when base > >> frequency is 1000 or 1200 MHz. The minimal value is updated from the > >> original 1.05V to 1.108V. > > Perhaps similiar to how a minimum of 1108 mV is useful when shifting to 1GHz, > using a minimum of 1132 is useful when shifting to 1.2GHz. Maybe... We can only wait if Marvell provide some details about this issue. > > (of course on 1.2 GHz variant you need to adjust values as only > > following frequencies 20 30 60 120 are supported) > > > > > > > > Marek > > > > > > > > > > > > > > > +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 > > > > > > > > Based on the below at boot time might an equivalent of the above need > > > > to be 1225 for 1.2GHz? > > > > > > > > 1200_750 > > > > SVC REV: 5, CPU VDD voltage: 1.225V > > > > > > > > 1000_800 > > > > SVC REV: 5, CPU VDD voltage: 1.108V > > > > This value is printed in WTMI avs.c by following code: > > > > shift = OTP_SVC_SPEED_1000_OFF; > > (OR) > > shift = OTP_SVC_SPEED_1200_OFF; > > > > vdd_otp = ((otp_data[OTP_DATA_SVC_SPEED_ID] >> shift) + > > AVS_VDD_BASE) & AVS_VDD_MASK; > > regval |= (vdd_otp << HIGH_VDD_LIMIT_OFF); > > regval |= (vdd_otp <<
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Wed, Feb 10, 2021, at 1:23 AM, Pali Rohár wrote:
> On Tuesday 09 February 2021 18:07:41 nnet wrote:
> > On Tue, Feb 9, 2021, at 5:51 PM, nnet wrote:
> > > On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote:
> > > > On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote:
> > > > > On Tue, 09 Feb 2021 15:16:45 -0800
> > > > > nnet wrote:
> > > > >
> > > > > > I've two of these and I've just swapped them (and re-pasted the
> > > > > > heat sinks).
> > > > > >
> > > > > > The second one ran under load for awhile and now has frozen as well.
> > > > > >
> > > > > > Under a moderate load `wget -O /dev/null ` @X00Mbits
> > > > > > they are fine.
> > > > > >
> > > > > > Under a 1 min speed test of load ~200Mbits routed WireGuard they
> > > > > > freeze.
> > > > > >
> > > > > > They fine with both those workloads @1000_800.
> > > > > >
> > > > > > Perhaps it's heat? Unfortunately I don't have any numbers on that
> > > > > > ATM.
> > > > >
> > > > > Try disabling cpufreq in kernel completely, compile boot image at
> > > > > 1200 MHz. If it continues freezing, then I fear we can't help you with
> > > > > 1200 MHz :(
> > > >
> > > > cat
> > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
> > > > 20 30 60 120
> > > >
> > > > I'm not getting any freezes with 1.2GHz fixed after 20 minutes of load:
> > > >
> > > > echo 120 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
> > > >
> > > > Setting it back to min 200MHz I get a freeze within a minute:
> > > >
> > > > echo 20 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
>
> Hello! Could you please enable userspace governor during kernel
> compilation?
>
> CONFIG_CPU_FREQ_GOV_USERSPACE=y
>
> It can be activated via command:
>
> echo userspace > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
>
> After that you can "force" CPU frequency to specific value, e.g.:
>
> echo 100 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
>
> I need to know which switch (from --> to freq) cause this system hang.
>
> This patch series (via MIN_VOLT_MV_FOR_L0_L1_1GHZ) is fixing only
> switching from 500 MHz to 1000 MHz on 1 GHz variant. As only this switch
> is causing issue.
>
> I have used following simple bash script to check that switching between
> 500 MHz and 1 GHz is stable:
>
> while true; do
> echo 100 >
> /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed;
> echo 50 >
> /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed;
> echo 100 >
> /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed;
> echo 50 >
> /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed;
> done
echo userspace | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
while true; do
echo 120 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed;
echo 60 | tee /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed;
done
>> +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108
With 1108 I get a freeze within a minute. The last output to stdout is 60.
With 1120 it takes a few minutes.
With any of 1225, 1155, 1132 the device doesn't freeze over the full 5 minute
load test.
I'm using ondemand now with the above at 1132 without issue so far.
>> Update the CPU voltage value for loads L0 and L1 accordingly when base
>> frequency is 1000 or 1200 MHz. The minimal value is updated from the
>> original 1.05V to 1.108V.
Perhaps similiar to how a minimum of 1108 mV is useful when shifting to 1GHz,
using a minimum of 1132 is useful when shifting to 1.2GHz.
> (of course on 1.2 GHz variant you need to adjust values as only
> following frequencies 20 30 60 120 are supported)
>
> > > > > Marek
> > > > >
> > >
> > > > +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108
> > >
> > > Based on the below at boot time might an equivalent of the above need
> > > to be 1225 for 1.2GHz?
> > >
> > > 1200_750
> > > SVC REV: 5, CPU VDD voltage: 1.225V
> > >
> > > 1000_800
> > > SVC REV: 5, CPU VDD voltage: 1.108V
>
> This value is printed in WTMI avs.c by following code:
>
> shift = OTP_SVC_SPEED_1000_OFF;
> (OR)
> shift = OTP_SVC_SPEED_1200_OFF;
>
> vdd_otp = ((otp_data[OTP_DATA_SVC_SPEED_ID] >> shift) +
> AVS_VDD_BASE) & AVS_VDD_MASK;
> regval |= (vdd_otp << HIGH_VDD_LIMIT_OFF);
> regval |= (vdd_otp << LOW_VDD_LIMIT_OFF);
> printf("SVC REV: %d, CPU VDD voltage: %s\n", svc_rev,
> avis_dump[vdd_otp].desc);
>
> So voltage value is read from the OTP memory.
>
> But I do not know what this value means.
>
> > I did this for a quick test for 1.2GHz:
> >
> > +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1225
> >
> > This is working well so far. Frequency is shifting up/down with load
> > applied/stopped.
>
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tuesday 09 February 2021 18:07:41 nnet wrote:
> On Tue, Feb 9, 2021, at 5:51 PM, nnet wrote:
> > On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote:
> > > On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote:
> > > > On Tue, 09 Feb 2021 15:16:45 -0800
> > > > nnet wrote:
> > > >
> > > > > I've two of these and I've just swapped them (and re-pasted the heat
> > > > > sinks).
> > > > >
> > > > > The second one ran under load for awhile and now has frozen as well.
> > > > >
> > > > > Under a moderate load `wget -O /dev/null ` @X00Mbits they
> > > > > are fine.
> > > > >
> > > > > Under a 1 min speed test of load ~200Mbits routed WireGuard they
> > > > > freeze.
> > > > >
> > > > > They fine with both those workloads @1000_800.
> > > > >
> > > > > Perhaps it's heat? Unfortunately I don't have any numbers on that ATM.
> > > >
> > > > Try disabling cpufreq in kernel completely, compile boot image at
> > > > 1200 MHz. If it continues freezing, then I fear we can't help you with
> > > > 1200 MHz :(
> > >
> > > cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
> > > 20 30 60 120
> > >
> > > I'm not getting any freezes with 1.2GHz fixed after 20 minutes of load:
> > >
> > > echo 120 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
> > >
> > > Setting it back to min 200MHz I get a freeze within a minute:
> > >
> > > echo 20 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
Hello! Could you please enable userspace governor during kernel
compilation?
CONFIG_CPU_FREQ_GOV_USERSPACE=y
It can be activated via command:
echo userspace > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
After that you can "force" CPU frequency to specific value, e.g.:
echo 100 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
I need to know which switch (from --> to freq) cause this system hang.
This patch series (via MIN_VOLT_MV_FOR_L0_L1_1GHZ) is fixing only
switching from 500 MHz to 1000 MHz on 1 GHz variant. As only this switch
is causing issue.
I have used following simple bash script to check that switching between
500 MHz and 1 GHz is stable:
while true; do
echo 100 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed;
echo 50 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed;
echo 100 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed;
echo 50 > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed;
done
(of course on 1.2 GHz variant you need to adjust values as only
following frequencies 20 30 60 120 are supported)
> > > > Marek
> > > >
> >
> > > +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108
> >
> > Based on the below at boot time might an equivalent of the above need
> > to be 1225 for 1.2GHz?
> >
> > 1200_750
> > SVC REV: 5, CPU VDD voltage: 1.225V
> >
> > 1000_800
> > SVC REV: 5, CPU VDD voltage: 1.108V
This value is printed in WTMI avs.c by following code:
shift = OTP_SVC_SPEED_1000_OFF;
(OR)
shift = OTP_SVC_SPEED_1200_OFF;
vdd_otp = ((otp_data[OTP_DATA_SVC_SPEED_ID] >> shift) +
AVS_VDD_BASE) & AVS_VDD_MASK;
regval |= (vdd_otp << HIGH_VDD_LIMIT_OFF);
regval |= (vdd_otp << LOW_VDD_LIMIT_OFF);
printf("SVC REV: %d, CPU VDD voltage: %s\n", svc_rev,
avis_dump[vdd_otp].desc);
So voltage value is read from the OTP memory.
But I do not know what this value means.
> I did this for a quick test for 1.2GHz:
>
> +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1225
>
> This is working well so far. Frequency is shifting up/down with load
> applied/stopped.
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tue, 09 Feb 2021 17:51:53 -0800 nnet wrote: > On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote: > > On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote: > > > On Tue, 09 Feb 2021 15:16:45 -0800 > > > nnet wrote: > > > > > > > I've two of these and I've just swapped them (and re-pasted the heat > > > > sinks). > > > > > > > > The second one ran under load for awhile and now has frozen as well. > > > > > > > > Under a moderate load `wget -O /dev/null ` @X00Mbits they > > > > are fine. > > > > > > > > Under a 1 min speed test of load ~200Mbits routed WireGuard they freeze. > > > > > > > > They fine with both those workloads @1000_800. > > > > > > > > Perhaps it's heat? Unfortunately I don't have any numbers on that ATM. > > > > > > Try disabling cpufreq in kernel completely, compile boot image at > > > 1200 MHz. If it continues freezing, then I fear we can't help you with > > > 1200 MHz :( > > > > cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies > > 20 30 60 120 > > > > I'm not getting any freezes with 1.2GHz fixed after 20 minutes of load: > > > > echo 120 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq > > > > Setting it back to min 200MHz I get a freeze within a minute: > > > > echo 20 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq > > > > > Marek > > > > > > +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 > > Based on the below at boot time might an equivalent of the above need to be > 1225 for 1.2GHz? > > 1200_750 > SVC REV: 5, CPU VDD voltage: 1.225V > > 1000_800 > SVC REV: 5, CPU VDD voltage: 1.108V It may be... But it is possible that the value 1.225 is computed by the code by default. Marek
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tue, Feb 9, 2021, at 5:51 PM, nnet wrote: > On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote: > > On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote: > > > On Tue, 09 Feb 2021 15:16:45 -0800 > > > nnet wrote: > > > > > > > I've two of these and I've just swapped them (and re-pasted the heat > > > > sinks). > > > > > > > > The second one ran under load for awhile and now has frozen as well. > > > > > > > > Under a moderate load `wget -O /dev/null ` @X00Mbits they > > > > are fine. > > > > > > > > Under a 1 min speed test of load ~200Mbits routed WireGuard they freeze. > > > > > > > > They fine with both those workloads @1000_800. > > > > > > > > Perhaps it's heat? Unfortunately I don't have any numbers on that ATM. > > > > > > Try disabling cpufreq in kernel completely, compile boot image at > > > 1200 MHz. If it continues freezing, then I fear we can't help you with > > > 1200 MHz :( > > > > cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies > > 20 30 60 120 > > > > I'm not getting any freezes with 1.2GHz fixed after 20 minutes of load: > > > > echo 120 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq > > > > Setting it back to min 200MHz I get a freeze within a minute: > > > > echo 20 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq > > > > > Marek > > > > > > +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 > > Based on the below at boot time might an equivalent of the above need > to be 1225 for 1.2GHz? > > 1200_750 > SVC REV: 5, CPU VDD voltage: 1.225V > > 1000_800 > SVC REV: 5, CPU VDD voltage: 1.108V I did this for a quick test for 1.2GHz: +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1225 This is working well so far. Frequency is shifting up/down with load applied/stopped.
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote: > On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote: > > On Tue, 09 Feb 2021 15:16:45 -0800 > > nnet wrote: > > > > > I've two of these and I've just swapped them (and re-pasted the heat > > > sinks). > > > > > > The second one ran under load for awhile and now has frozen as well. > > > > > > Under a moderate load `wget -O /dev/null ` @X00Mbits they are > > > fine. > > > > > > Under a 1 min speed test of load ~200Mbits routed WireGuard they freeze. > > > > > > They fine with both those workloads @1000_800. > > > > > > Perhaps it's heat? Unfortunately I don't have any numbers on that ATM. > > > > Try disabling cpufreq in kernel completely, compile boot image at > > 1200 MHz. If it continues freezing, then I fear we can't help you with > > 1200 MHz :( > > cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies > 20 30 60 120 > > I'm not getting any freezes with 1.2GHz fixed after 20 minutes of load: > > echo 120 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq > > Setting it back to min 200MHz I get a freeze within a minute: > > echo 20 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq > > > Marek > > > +#define MIN_VOLT_MV_FOR_L0_L1_1GHZ 1108 Based on the below at boot time might an equivalent of the above need to be 1225 for 1.2GHz? 1200_750 SVC REV: 5, CPU VDD voltage: 1.225V 1000_800 SVC REV: 5, CPU VDD voltage: 1.108V
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote: > On Tue, 09 Feb 2021 15:16:45 -0800 > nnet wrote: > > > I've two of these and I've just swapped them (and re-pasted the heat sinks). > > > > The second one ran under load for awhile and now has frozen as well. > > > > Under a moderate load `wget -O /dev/null ` @X00Mbits they are > > fine. > > > > Under a 1 min speed test of load ~200Mbits routed WireGuard they freeze. > > > > They fine with both those workloads @1000_800. > > > > Perhaps it's heat? Unfortunately I don't have any numbers on that ATM. > > Try disabling cpufreq in kernel completely, compile boot image at > 1200 MHz. If it continues freezing, then I fear we can't help you with > 1200 MHz :( cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 20 30 60 120 I'm not getting any freezes with 1.2GHz fixed after 20 minutes of load: echo 120 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq Setting it back to min 200MHz I get a freeze within a minute: echo 20 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq > Marek >
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tue, 09 Feb 2021 15:16:45 -0800 nnet wrote: > I've two of these and I've just swapped them (and re-pasted the heat sinks). > > The second one ran under load for awhile and now has frozen as well. > > Under a moderate load `wget -O /dev/null ` @X00Mbits they are fine. > > Under a 1 min speed test of load ~200Mbits routed WireGuard they freeze. > > They fine with both those workloads @1000_800. > > Perhaps it's heat? Unfortunately I don't have any numbers on that ATM. Try disabling cpufreq in kernel completely, compile boot image at 1200 MHz. If it continues freezing, then I fear we can't help you with 1200 MHz :( Marek
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
I've two of these and I've just swapped them (and re-pasted the heat sinks). The second one ran under load for awhile and now has frozen as well. Under a moderate load `wget -O /dev/null ` @X00Mbits they are fine. Under a 1 min speed test of load ~200Mbits routed WireGuard they freeze. They fine with both those workloads @1000_800. Perhaps it's heat? Unfortunately I don't have any numbers on that ATM. On Tue, Feb 9, 2021, at 2:56 PM, Pali Rohár wrote: > On Tuesday 09 February 2021 14:52:56 nnet wrote: > > On Tue, Feb 9, 2021, at 2:42 PM, Pali Rohár wrote: > > > On Tuesday 09 February 2021 13:45:08 nnet wrote: > > > > On Tue, Feb 9, 2021, at 1:33 PM, Pali Rohár wrote: > > > > > On Tuesday 09 February 2021 13:00:26 nnet wrote: > > > > > > > If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, > > > > > > > Devel Board, ...) then it will be nice to do an additional tests > > > > > > > and check if instability issues are finally fixed. > > > > > > > > > > > > These patches applied to the 5.4.96 in OpenWrt (98d61b5) work fine > > > > > > so far on an Espressobin v7 AFAICT per changing values in > > > > > > /sys/devices/system/cpu/cpufreq/policy0. > > > > > > > > > > > > Are these changes intended to work @1.2 GHz on the v7? > > > > > > > > > > Hello! Do you have 1.2 GHz A3720 SoC? > > > > > > > > Maybe (not)? ESPRESSObin_V7_1-0 on the underside. > > > > > > Look at the package of SoC chip. On top of the package is printed > > > identifier 88F3720. On the last line should be one of the string: > > > C080, C100, C120, I080, I100 which identifies frequency > > > (080 = 800 MHz, 100 = 1 GHz, 120 = 1.2 GHz) > > > > > > Can you check what is printed on A3720 SoC package? > > > > Both of mine are 88F3720-A0-C120. > > Interesting... it is really 1.2 GHz. I have not seen it yet. And few > weeks ago I thought that it was never available on market. > > Well, if 1.2 GHz variant has same issues as 1 GHz variants then this > patch series should fix it. But you said that with this patch series is > board crashing when running at 1.2 GHz? >
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tuesday 09 February 2021 14:52:56 nnet wrote: > On Tue, Feb 9, 2021, at 2:42 PM, Pali Rohár wrote: > > On Tuesday 09 February 2021 13:45:08 nnet wrote: > > > On Tue, Feb 9, 2021, at 1:33 PM, Pali Rohár wrote: > > > > On Tuesday 09 February 2021 13:00:26 nnet wrote: > > > > > > If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, > > > > > > Devel Board, ...) then it will be nice to do an additional tests > > > > > > and check if instability issues are finally fixed. > > > > > > > > > > These patches applied to the 5.4.96 in OpenWrt (98d61b5) work fine so > > > > > far on an Espressobin v7 AFAICT per changing values in > > > > > /sys/devices/system/cpu/cpufreq/policy0. > > > > > > > > > > Are these changes intended to work @1.2 GHz on the v7? > > > > > > > > Hello! Do you have 1.2 GHz A3720 SoC? > > > > > > Maybe (not)? ESPRESSObin_V7_1-0 on the underside. > > > > Look at the package of SoC chip. On top of the package is printed > > identifier 88F3720. On the last line should be one of the string: > > C080, C100, C120, I080, I100 which identifies frequency > > (080 = 800 MHz, 100 = 1 GHz, 120 = 1.2 GHz) > > > > Can you check what is printed on A3720 SoC package? > > Both of mine are 88F3720-A0-C120. Interesting... it is really 1.2 GHz. I have not seen it yet. And few weeks ago I thought that it was never available on market. Well, if 1.2 GHz variant has same issues as 1 GHz variants then this patch series should fix it. But you said that with this patch series is board crashing when running at 1.2 GHz?
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tue, Feb 9, 2021, at 2:42 PM, Pali Rohár wrote: > On Tuesday 09 February 2021 13:45:08 nnet wrote: > > On Tue, Feb 9, 2021, at 1:33 PM, Pali Rohár wrote: > > > On Tuesday 09 February 2021 13:00:26 nnet wrote: > > > > > If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, Devel > > > > > Board, ...) then it will be nice to do an additional tests and check > > > > > if instability issues are finally fixed. > > > > > > > > These patches applied to the 5.4.96 in OpenWrt (98d61b5) work fine so > > > > far on an Espressobin v7 AFAICT per changing values in > > > > /sys/devices/system/cpu/cpufreq/policy0. > > > > > > > > Are these changes intended to work @1.2 GHz on the v7? > > > > > > Hello! Do you have 1.2 GHz A3720 SoC? > > > > Maybe (not)? ESPRESSObin_V7_1-0 on the underside. > > Look at the package of SoC chip. On top of the package is printed > identifier 88F3720. On the last line should be one of the string: > C080, C100, C120, I080, I100 which identifies frequency > (080 = 800 MHz, 100 = 1 GHz, 120 = 1.2 GHz) > > Can you check what is printed on A3720 SoC package? Both of mine are 88F3720-A0-C120.
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tuesday 09 February 2021 13:45:08 nnet wrote: > On Tue, Feb 9, 2021, at 1:33 PM, Pali Rohár wrote: > > On Tuesday 09 February 2021 13:00:26 nnet wrote: > > > > If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, Devel > > > > Board, ...) then it will be nice to do an additional tests and check if > > > > instability issues are finally fixed. > > > > > > These patches applied to the 5.4.96 in OpenWrt (98d61b5) work fine so far > > > on an Espressobin v7 AFAICT per changing values in > > > /sys/devices/system/cpu/cpufreq/policy0. > > > > > > Are these changes intended to work @1.2 GHz on the v7? > > > > Hello! Do you have 1.2 GHz A3720 SoC? > > Maybe (not)? ESPRESSObin_V7_1-0 on the underside. Look at the package of SoC chip. On top of the package is printed identifier 88F3720. On the last line should be one of the string: C080, C100, C120, I080, I100 which identifies frequency (080 = 800 MHz, 100 = 1 GHz, 120 = 1.2 GHz) Can you check what is printed on A3720 SoC package? > BTW, with the 1200_750 firmware and the patches: > > root@OpenWrt:/sys/devices/system/cpu/cpufreq/policy0# cat > scaling_available_frequencies > 20 30 60 120 > > Of course that could mean nothing, but thought I'd mention what I do see. This is value set by firmware file which you have started.
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tue, Feb 9, 2021, at 1:33 PM, Pali Rohár wrote: > On Tuesday 09 February 2021 13:00:26 nnet wrote: > > > If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, Devel > > > Board, ...) then it will be nice to do an additional tests and check if > > > instability issues are finally fixed. > > > > These patches applied to the 5.4.96 in OpenWrt (98d61b5) work fine so far > > on an Espressobin v7 AFAICT per changing values in > > /sys/devices/system/cpu/cpufreq/policy0. > > > > Are these changes intended to work @1.2 GHz on the v7? > > Hello! Do you have 1.2 GHz A3720 SoC? Maybe (not)? ESPRESSObin_V7_1-0 on the underside. BTW, with the 1200_750 firmware and the patches: root@OpenWrt:/sys/devices/system/cpu/cpufreq/policy0# cat scaling_available_frequencies 20 30 60 120 Of course that could mean nothing, but thought I'd mention what I do see.
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
On Tuesday 09 February 2021 13:00:26 nnet wrote: > > If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, Devel Board, > > ...) then it will be nice to do an additional tests and check if > > instability issues are finally fixed. > > These patches applied to the 5.4.96 in OpenWrt (98d61b5) work fine so far on > an Espressobin v7 AFAICT per changing values in > /sys/devices/system/cpu/cpufreq/policy0. > > Are these changes intended to work @1.2 GHz on the v7? Hello! Do you have 1.2 GHz A3720 SoC?
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
> If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, Devel Board, > ...) then it will be nice to do an additional tests and check if instability > issues are finally fixed. These patches applied to the 5.4.96 in OpenWrt (98d61b5) work fine so far on an Espressobin v7 AFAICT per changing values in /sys/devices/system/cpu/cpufreq/policy0. Are these changes intended to work @1.2 GHz on the v7? I have the beige case and heat-sinks with paste on the board, and the power adapter is the Fairway for 2.0A. However, the device hangs fairly quickly under load with firmware flashed of the built as below: diff --git a/package/boot/arm-trusted-firmware-mvebu/Makefile b/package/boot/arm-trusted-firmware-mvebu/Makefile index c4669edb52..20899c29e7 100644 --- a/package/boot/arm-trusted-firmware-mvebu/Makefile +++ b/package/boot/arm-trusted-firmware-mvebu/Makefile @@ -72,7 +72,7 @@ define Trusted-Firmware-A/espressobin-v7-1gb BUILD_DEVICES:=globalscale_espressobin-v7 UBOOT:=espressobin DDR_TOPOLOGY:=5 - CLOCKSPRESET:=CPU_1000_DDR_800 + CLOCKSPRESET:=CPU_1200_DDR_750 PLAT:=a3700 endef See: https://github.com/openwrt/openwrt/commit/5fae94d987f2261b148c035130a00350c905a13e
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
Hi Marek & Pali On 1/14/21 1:40 PM, Pali Rohár wrote: Hello! The armada-37xx-cpufreq driver changes base CPU speed from 1000 MHz to 800 MHz on EspressoBIN and Turris MOX. The commit message in patch 2/10 explains why and how can this be discovered. That patch 2/10 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 systems with base frequency 1 GHz, we also have to set voltage levels for L0 and L1 loads to at least 1108 mV. We were led to this by patch we found in Marvell kernel fork. Fix is in the patch 4/10. https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/dc33b62c90696afb6adc7dbcc4ebbd48bedec269 During fixing this voltage issue for 1 GHz we discovered another bug in armada-37xx-cpufreq driver that causes CPU instability. Erratum for VDD stabilization was improperly implemented, details are in patch 6/10. This patch series is also available in my git tree in branch a3720-cpufreq-issues: https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=a3720-cpufreq-issues We have tested this patch series on Espressobin v5 and Turris MOX boards. If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, Devel Board, ...) then it will be nice to do an additional tests and check if instability issues are finally fixed. There is a discussion on armbian forum that Espressobin v7 is unstable when running at 1 GHz and in this thread was also mentioned above voltage patch from Marvell kernel fork: https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/ Marek & Pali Marek Behún (3): arm64: dts: marvell: armada-37xx: add syscon compatible to NB clk node cpufreq: armada-37xx: Fix setting TBG parent for load levels clk: mvebu: armada-37xx-periph: remove .set_parent method for CPU PM clock Pali Rohár (7): cpufreq: armada-37xx: Fix the AVS value for loads L0 and L1 clk: mvebu: armada-37xx-periph: Fix switching CPU freq from 250 Mhz to 1 GHz clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1 to L0 cpufreq: armada-37xx: Fix driver cleanup when registration failed cpufreq: armada-37xx: Fix determining base CPU frequency cpufreq: armada-37xx: Remove cur_frequency variable cpufreq: armada-37xx: Fix module unloading arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 3 +- drivers/clk/mvebu/armada-37xx-periph.c | 83 --- drivers/cpufreq/armada-37xx-cpufreq.c| 100 ++- 3 files changed, 124 insertions(+), 62 deletions(-) Thank you for looking at this problem! I have tested your a3720-cpufreq-issues branch on my Espressobin v7 (1GB variant) with the ondemand governor. No issues so far. root@espressobin:~# uname -a Linux espressobin 5.11.0-rc1+ #1 SMP PREEMPT Sun Jan 31 23:35:17 CET 2021 aarch64 aarch64 aarch64 GNU/Linux root@espressobin:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpuf...@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:34.71%, 250 MHz:13.20%, 500 MHz:6.26%, 1000 MHz:45.83% (2015) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 500 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:34.71%, 250 MHz:13.20%, 500 MHz:6.26%, 1000 MHz:45.83% (2015) root@espressobin:~# 7za b 7-Zip (a) [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: 974 997 993 996 997 997 996 997 RAM size: 983 MB, # CPU hardware threads:
Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz
W dniu 14.01.2021 o 13:40, Pali Rohár pisze: > Hello! > > The armada-37xx-cpufreq driver changes base CPU speed from 1000 MHz to > 800 MHz on EspressoBIN and Turris MOX. The commit message in patch 2/10 > explains why and how can this be discovered. > > That patch 2/10 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 > systems with base frequency 1 GHz, we also have to set voltage levels > for L0 and L1 loads to at least 1108 mV. We were led to this by patch we > found in Marvell kernel fork. Fix is in the patch 4/10. > > https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/dc33b62c90696afb6adc7dbcc4ebbd48bedec269 > > During fixing this voltage issue for 1 GHz we discovered another bug in > armada-37xx-cpufreq driver that causes CPU instability. Erratum for VDD > stabilization was improperly implemented, details are in patch 6/10. > > This patch series is also available in my git tree in branch > a3720-cpufreq-issues: > > https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=a3720-cpufreq-issues > > We have tested this patch series on Espressobin v5 and Turris MOX > boards. If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, > Devel Board, ...) then it will be nice to do an additional tests and > check if instability issues are finally fixed. > > There is a discussion on armbian forum that Espressobin v7 is unstable > when running at 1 GHz and in this thread was also mentioned above > voltage patch from Marvell kernel fork: > > https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/ > > Marek & Pali > > > Marek Behún (3): > arm64: dts: marvell: armada-37xx: add syscon compatible to NB clk node > cpufreq: armada-37xx: Fix setting TBG parent for load levels > clk: mvebu: armada-37xx-periph: remove .set_parent method for CPU PM > clock > > Pali Rohár (7): > cpufreq: armada-37xx: Fix the AVS value for loads L0 and L1 > clk: mvebu: armada-37xx-periph: Fix switching CPU freq from 250 Mhz to > 1 GHz > clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1 > to L0 > cpufreq: armada-37xx: Fix driver cleanup when registration failed > cpufreq: armada-37xx: Fix determining base CPU frequency > cpufreq: armada-37xx: Remove cur_frequency variable > cpufreq: armada-37xx: Fix module unloading Hi. After running this series for three days, the system is stable and the issue with switching frequency doesn't seem to be there anymore. So: Tested-by: Tomasz Maciej Nowak Thanks. > > arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 3 +- > drivers/clk/mvebu/armada-37xx-periph.c | 83 --- > drivers/cpufreq/armada-37xx-cpufreq.c| 100 ++- > 3 files changed, 124 insertions(+), 62 deletions(-) > -- TMN
