Re: [BUG] Error applying setting, reverse things back on lot of devices
Hello, On 11/8/20 6:08 PM, Michał Mirosław wrote: > On Thu, Nov 05, 2020 at 10:11:30AM +0100, Ahmad Fatoum wrote: > It seems that final regulator_resolve_supply() is spinning recursively. > Is the regulator name the same as its supply_name? Can you try the patch > below to verify this? Indeed that seems to be the case: [1.299103] stpmic1 1-0033: PMIC Chip Version: 0x10 [1.307872] vddcore: 1200 <--> 1350 mV at 1200 mV, enabled [1.312173] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply buck1 for BUCK1 [1.321083] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck1-supply from device tree [1.330838] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck1-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed [1.344650] vddcore: supplied by regulator-dummy [1.352016] vdd_ddr: 1350 mV, enabled [1.354421] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply buck2 for BUCK2 [1.363341] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck2-supply from device tree [1.373124] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck2-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed [1.386921] vdd_ddr: supplied by regulator-dummy [1.394230] vdd: 3300 mV, enabled [1.396307] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply buck3 for BUCK3 [1.405186] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck3-supply from device tree [1.414962] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck3-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed [1.428790] vdd: supplied by regulator-dummy [1.435880] v3v3: 3300 mV, enabled [1.438008] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply buck4 for BUCK4 [1.446934] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up buck4-supply from device tree [1.456681] v3v3: supplied by 5V2 [1.462533] v1v8_audio: 1800 mV, enabled [1.465218] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply ldo1 for LDO1 [1.473906] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo1-supply from device tree [1.483611] v1v8_audio: supplied by v3v3 [1.490978] v3v3_hdmi: 3300 mV, enabled [1.493551] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply ldo2 for LDO2 [1.502309] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo2-supply from device tree [1.511959] v3v3_hdmi: supplied by 5V2 [1.516320] vtt_ddr: override max_uV, 75 -> 50 [1.523538] vtt_ddr: 500 mV, enabled [1.525881] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply ldo3 for LDO3 [1.534555] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo3-supply from device tree [1.544285] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo3-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed [1.558017] vtt_ddr: supplied by regulator-dummy [1.562874] vdd_usb: 3300 mV, enabled [1.566585] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply ldo4 for LDO4 [1.575297] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo4-supply from device tree [1.585031] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo4-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed [1.598716] vdd_usb: supplied by regulator-dummy [1.605030] edt_ft5x06 0-0038: touchscreen probe failed [1.606247] vdda: 2900 mV, enabled [1.612496] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply ldo5 for LDO5 [1.621251] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo5-supply from device tree [1.630888] vdda: supplied by 5V2 [1.637155] v1v2_hdmi: 1200 mV, enabled [1.639742] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply ldo6 for LDO6 [1.648473] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up ldo6-supply from device tree [1.658143] v1v2_hdmi: supplied by v3v3 [1.664926] vref_ddr: at 500 mV, enabled [1.667597] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply vref_ddr for VREF_DDR [1.677055] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up vref_ddr-supply from device tree [1.687091] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up vref_ddr-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed [1.701181] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Supply for VREF_DDR (vref_ddr) resolved to itself [1.711713] vref_ddr: unable to resolve supply [1.716413] bst_out: at 5000 mV, disabled [1.720445] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Resolving supply vref_ddr for
Re: [BUG] Error applying setting, reverse things back on lot of devices
On Thu, Nov 05, 2020 at 10:11:30AM +0100, Ahmad Fatoum wrote:
> Hello,
>
> On 11/5/20 3:57 AM, Michał Mirosław wrote:
> >>> Can you catch debug logs for the bootup in question? I'm not sure what's
> >>> the failure mode in your case. I guess this is not a bypassed regulator?
> >>
> >> Boot up with v5.10-rc2 + your cf1ad559a2 ("regulator: defer probe when
> >> trying
> >> to get voltage from unresolved supply") hangs:
> >>
> >> [1.151489] stm32f7-i2c 40015000.i2c: STM32F7 I2C-0 bus adapter
> >> [1.180698] stpmic1 1-0033: PMIC Chip Version: 0x10
> >> [1.189526] vddcore: supplied by regulator-dummy
> >> [1.195633] vdd_ddr: supplied by regulator-dummy
> >> [1.201672] vdd: supplied by regulator-dummy
> >> [1.207452] v3v3: supplied by 5V2
> >> [1.211997] v1v8_audio: supplied by v3v3
> >> [1.218036] v3v3_hdmi: supplied by 5V2
> >> [1.223626] vtt_ddr: supplied by regulator-dummy
> >> [1.227107] vdd_usb: supplied by regulator-dummy
> >> [1.234532] vdda: supplied by 5V2
> >> [1.239497] v1v2_hdmi: supplied by v3v3
> > [...]
> >
> > Can you try with the patches I just sent and with debug logs enabled?
> >
> > The first one just plugs a memory leak, but if there is some state
> > changed/saved in the rdev->constraints (can't find that code, though),
> > this might prevent it from being overwritten.
> >
> > The second patch will just tell us if you hit the early resolve case.
>
> Problem still persists. Early resolve case not hit:
[...]
> [1.594492] vref_ddr: at 500 mV, enabled
> [1.597047] edt_ft5x06 0-0038: touchscreen probe failed
> [1.597211] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking
> up vref_ddr-supply from device tree
> [1.612406] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking
> up vref_ddr-supply property in node /soc/i2c@5c002000/stpmic@33/regulators
> failed
>
> [ snip - continues many times ]
>
> [6.699244] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking
> up vref_ddr-supply property in node /soc/i2c@5c002000/stpmic@33/regulators
> failed
> [6.713312] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking
> up vref_ddr-supply from device tree
It seems that final regulator_resolve_supply() is spinning recursively.
Is the regulator name the same as its supply_name? Can you try the patch
below to verify this?
Best Regards
Michał Mirosław
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index c84e3b0b63de..983a4bd3e98c 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1798,6 +1798,8 @@ static int regulator_resolve_supply(struct regulator_dev
*rdev)
if (rdev->supply)
return 0;
+ dev_dbg(dev, "Resolving supply %s for %s\n", rdev->supply_name,
rdev->desc->name);
+
r = regulator_dev_lookup(dev, rdev->supply_name);
if (IS_ERR(r)) {
ret = PTR_ERR(r);
@@ -1816,6 +1818,12 @@ static int regulator_resolve_supply(struct regulator_dev
*rdev)
}
}
+ if (r == rdev) {
+ dev_err(dev, "Supply for %s (%s) resolved to itself\n",
+ rdev->desc->name, rdev->supply_name);
+ return -EINVAL;
+ }
+
/*
* If the supply's parent device is not the same as the
* regulator's parent device, then ensure the parent device
Re: [BUG] Error applying setting, reverse things back on lot of devices
Hello,
On 11/5/20 3:57 AM, Michał Mirosław wrote:
>>> Can you catch debug logs for the bootup in question? I'm not sure what's
>>> the failure mode in your case. I guess this is not a bypassed regulator?
>>
>> Boot up with v5.10-rc2 + your cf1ad559a2 ("regulator: defer probe when trying
>> to get voltage from unresolved supply") hangs:
>>
>> [1.151489] stm32f7-i2c 40015000.i2c: STM32F7 I2C-0 bus adapter
>> [1.180698] stpmic1 1-0033: PMIC Chip Version: 0x10
>> [1.189526] vddcore: supplied by regulator-dummy
>> [1.195633] vdd_ddr: supplied by regulator-dummy
>> [1.201672] vdd: supplied by regulator-dummy
>> [1.207452] v3v3: supplied by 5V2
>> [1.211997] v1v8_audio: supplied by v3v3
>> [1.218036] v3v3_hdmi: supplied by 5V2
>> [1.223626] vtt_ddr: supplied by regulator-dummy
>> [1.227107] vdd_usb: supplied by regulator-dummy
>> [1.234532] vdda: supplied by 5V2
>> [1.239497] v1v2_hdmi: supplied by v3v3
> [...]
>
> Can you try with the patches I just sent and with debug logs enabled?
>
> The first one just plugs a memory leak, but if there is some state
> changed/saved in the rdev->constraints (can't find that code, though),
> this might prevent it from being overwritten.
>
> The second patch will just tell us if you hit the early resolve case.
Problem still persists. Early resolve case not hit:
[1.231096] i2c /dev entries driver
[1.258111] stm32f7-i2c 40015000.i2c: STM32F7 I2C-0 bus adapter
[1.258348] edt_ft5x06 0-0038: Looking up vcc-supply from device tree
[1.287207] stpmic1 1-0033: PMIC Chip Version: 0x10
[1.295810] vddcore: 1200 <--> 1350 mV at 1200 mV, enabled
[1.300108] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
buck1-supply from device tree
[1.309747] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
buck1-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed
[1.323526] vddcore: supplied by regulator-dummy
[1.334951] vdd_ddr: 1350 mV, enabled
[1.337356] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
buck2-supply from device tree
[1.347016] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
buck2-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed
[1.360805] vdd_ddr: supplied by regulator-dummy
[1.372166] vdd: 3300 mV, enabled
[1.374211] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
buck3-supply from device tree
[1.383863] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
buck3-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed
[1.397656] vdd: supplied by regulator-dummy
[1.408473] v3v3: 3300 mV, enabled
[1.410597] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
buck4-supply from device tree
[1.420244] v3v3: supplied by 5V2
[1.428843] v1v8_audio: 1800 mV, enabled
[1.431502] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
ldo1-supply from device tree
[1.441049] v1v8_audio: supplied by v3v3
[1.451744] v3v3_hdmi: 3300 mV, enabled
[1.454310] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
ldo2-supply from device tree
[1.463864] v3v3_hdmi: supplied by 5V2
[1.471367] vtt_ddr: override max_uV, 75 -> 50
[1.478650] vtt_ddr: 500 mV, enabled
[1.480958] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
ldo3-supply from device tree
[1.490526] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
ldo3-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed
[1.504227] vtt_ddr: supplied by regulator-dummy
[1.513158] vdd_usb: 3300 mV, enabled
[1.516875] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
ldo4-supply from device tree
[1.526410] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
ldo4-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed
[1.540133] vdd_usb: supplied by regulator-dummy
[1.551741] vdda: 2900 mV, enabled
[1.553864] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
ldo5-supply from device tree
[1.563415] vdda: supplied by 5V2
[1.572357] v1v2_hdmi: 1200 mV, enabled
[1.574970] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
ldo6-supply from device tree
[1.584441] v1v2_hdmi: supplied by v3v3
[1.594492] vref_ddr: at 500 mV, enabled
[1.597047] edt_ft5x06 0-0038: touchscreen probe failed
[1.597211] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
vref_ddr-supply from device tree
[1.612406] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
vref_ddr-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed
[ snip - continues many times ]
[6.699244] stpmic1-regulator 5c002000.i2c:stpmic@33:regulators: Looking up
vref_ddr-supply property in node /soc/i2c@5c002000/stpmic@33/regulators failed
[
Re: [Linux-stm32] [BUG] Error applying setting, reverse things back on lot of devices
Hello Alex,
On 11/4/20 11:50 AM, Alexandre Torgue wrote:
>> Boot up with v5.10-rc2 + your cf1ad559a2 + { regulators {
>> vref_ddr-supply = <_5v2>; }
>
> Just to know, Did you test v5.10-rc2 + vref_ddr-supply = <_5v2>; ? (which
> seems to correspond to the patch I sent for DK/EV STM32 boards)
I did yes, it masks the issue and allows the system to boot.
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [BUG] Error applying setting, reverse things back on lot of devices
On Wed, Nov 04, 2020 at 11:28:45AM +0100, Ahmad Fatoum wrote:
> Hello,
>
> On 11/2/20 9:27 PM, Michał Mirosław wrote:
> > On Mon, Nov 02, 2020 at 01:48:54PM +0100, Ahmad Fatoum wrote:
> >> Hello Michał,
> >>
> >> CC += linux-stm32
> >>
> >> On 10/24/20 1:53 PM, Michał Mirosław wrote:
> >>> On Fri, Oct 23, 2020 at 10:39:43PM +0200, Corentin Labbe wrote:
> On Fri, Oct 23, 2020 at 03:42:01PM +0200, Corentin Labbe wrote:
> > On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote:
> > I have just saw thoses 3 lines which are probably the real problem.
> > I have started a new bisect with this error, but it is hitting the same
> > "crash range" the first one.
> >
>
> I have bisected the problem to commit
> aea6cb99703e17019e025aa71643b4d3e0a24413 ("regulator: resolve supply
> after creating regulator")
> Reverting this fix my problem.
> >>
> >> The change broke boot on all the STM32MP1 boards, because the STPMIC driver
> >> has a vref_ddr regulator, which does not have a dedicated supply, but
> >> without
> >> a vref_ddr-supply property the system now no longer boots.
> > [...]
> >
> > Can you catch debug logs for the bootup in question? I'm not sure what's
> > the failure mode in your case. I guess this is not a bypassed regulator?
>
> Boot up with v5.10-rc2 + your cf1ad559a2 ("regulator: defer probe when trying
> to get voltage from unresolved supply") hangs:
>
> [1.151489] stm32f7-i2c 40015000.i2c: STM32F7 I2C-0 bus adapter
> [1.180698] stpmic1 1-0033: PMIC Chip Version: 0x10
> [1.189526] vddcore: supplied by regulator-dummy
> [1.195633] vdd_ddr: supplied by regulator-dummy
> [1.201672] vdd: supplied by regulator-dummy
> [1.207452] v3v3: supplied by 5V2
> [1.211997] v1v8_audio: supplied by v3v3
> [1.218036] v3v3_hdmi: supplied by 5V2
> [1.223626] vtt_ddr: supplied by regulator-dummy
> [1.227107] vdd_usb: supplied by regulator-dummy
> [1.234532] vdda: supplied by 5V2
> [1.239497] v1v2_hdmi: supplied by v3v3
[...]
Can you try with the patches I just sent and with debug logs enabled?
The first one just plugs a memory leak, but if there is some state
changed/saved in the rdev->constraints (can't find that code, though),
this might prevent it from being overwritten.
The second patch will just tell us if you hit the early resolve case.
Best Regards,
Michał Mirosław
Re: [Linux-stm32] [BUG] Error applying setting, reverse things back on lot of devices
Hi Ahmad
On 11/4/20 11:28 AM, Ahmad Fatoum wrote:
Hello,
On 11/2/20 9:27 PM, Michał Mirosław wrote:
On Mon, Nov 02, 2020 at 01:48:54PM +0100, Ahmad Fatoum wrote:
Hello Michał,
CC += linux-stm32
On 10/24/20 1:53 PM, Michał Mirosław wrote:
On Fri, Oct 23, 2020 at 10:39:43PM +0200, Corentin Labbe wrote:
On Fri, Oct 23, 2020 at 03:42:01PM +0200, Corentin Labbe wrote:
On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote:
I have just saw thoses 3 lines which are probably the real problem.
I have started a new bisect with this error, but it is hitting the same "crash
range" the first one.
I have bisected the problem to commit aea6cb99703e17019e025aa71643b4d3e0a24413
("regulator: resolve supply after creating regulator")
Reverting this fix my problem.
The change broke boot on all the STM32MP1 boards, because the STPMIC driver
has a vref_ddr regulator, which does not have a dedicated supply, but without
a vref_ddr-supply property the system now no longer boots.
[...]
Can you catch debug logs for the bootup in question? I'm not sure what's
the failure mode in your case. I guess this is not a bypassed regulator?
Boot up with v5.10-rc2 + your cf1ad559a2 ("regulator: defer probe when trying
to get voltage from unresolved supply") hangs:
[1.151489] stm32f7-i2c 40015000.i2c: STM32F7 I2C-0 bus adapter
[1.180698] stpmic1 1-0033: PMIC Chip Version: 0x10
[1.189526] vddcore: supplied by regulator-dummy
[1.195633] vdd_ddr: supplied by regulator-dummy
[1.201672] vdd: supplied by regulator-dummy
[1.207452] v3v3: supplied by 5V2
[1.211997] v1v8_audio: supplied by v3v3
[1.218036] v3v3_hdmi: supplied by 5V2
[1.223626] vtt_ddr: supplied by regulator-dummy
[1.227107] vdd_usb: supplied by regulator-dummy
[1.234532] vdda: supplied by 5V2
[1.239497] v1v2_hdmi: supplied by v3v3
Boot up with v5.10-rc2 with aea6cb99 ("regulator: resolve supply after
creating regulator") reverted boots correctly:
[1.151458] stm32f7-i2c 40015000.i2c: STM32F7 I2C-0 bus adapter
[1.180668] stpmic1 1-0033: PMIC Chip Version: 0x10
[1.186629] BUCK1: supplied by regulator-dummy
[1.192628] BUCK2: supplied by regulator-dummy
[1.198667] BUCK3: supplied by regulator-dummy
[1.204623] BUCK4: supplied by 5V2
[1.209424] LDO1: supplied by v3v3
[1.214931] LDO2: supplied by 5V2
[1.219897] LDO3: supplied by regulator-dummy
[1.225784] LDO4: supplied by regulator-dummy
[1.229239] LDO5: supplied by 5V2
[1.235097] LDO6: supplied by v3v3
[1.240164] VREF_DDR: supplied by regulator-dummy
[1.246130] BOOST: supplied by 5V2
[1.248617] VBUS_OTG: supplied by bst_out
[1.252698] SW_OUT: supplied by bst_out
Boot up with v5.10-rc2 + your cf1ad559a2 + { regulators { vref_ddr-supply =
<_5v2>; }
Just to know, Did you test v5.10-rc2 + vref_ddr-supply = <_5v2>; ?
(which seems to correspond to the patch I sent for DK/EV STM32 boards)
boots correctly as well:
[1.151531] stm32f7-i2c 40015000.i2c: STM32F7 I2C-0 bus adapter
[1.180759] stpmic1 1-0033: PMIC Chip Version: 0x10
[1.189543] vddcore: supplied by regulator-dummy
[1.195651] vdd_ddr: supplied by regulator-dummy
[1.201687] vdd: supplied by regulator-dummy
[1.207470] v3v3: supplied by 5V2
[1.212015] v1v8_audio: supplied by v3v3
[1.218053] v3v3_hdmi: supplied by 5V2
[1.223647] vtt_ddr: supplied by regulator-dummy
[1.227128] vdd_usb: supplied by regulator-dummy
[1.234553] vdda: supplied by 5V2
[1.239510] v1v2_hdmi: supplied by v3v3
[1.244932] vref_ddr: supplied by 5V2
[1.247397] bst_out: supplied by 5V2
[1.251338] vbus_otg: supplied by bst_out
[1.255416] vbus_sw: supplied by bst_out
Cheers
Ahmad
Best Regards,
Michał Mirosław
Re: [BUG] Error applying setting, reverse things back on lot of devices
Hello,
On 11/2/20 9:27 PM, Michał Mirosław wrote:
> On Mon, Nov 02, 2020 at 01:48:54PM +0100, Ahmad Fatoum wrote:
>> Hello Michał,
>>
>> CC += linux-stm32
>>
>> On 10/24/20 1:53 PM, Michał Mirosław wrote:
>>> On Fri, Oct 23, 2020 at 10:39:43PM +0200, Corentin Labbe wrote:
On Fri, Oct 23, 2020 at 03:42:01PM +0200, Corentin Labbe wrote:
> On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote:
> I have just saw thoses 3 lines which are probably the real problem.
> I have started a new bisect with this error, but it is hitting the same
> "crash range" the first one.
>
I have bisected the problem to commit
aea6cb99703e17019e025aa71643b4d3e0a24413 ("regulator: resolve supply after
creating regulator")
Reverting this fix my problem.
>>
>> The change broke boot on all the STM32MP1 boards, because the STPMIC driver
>> has a vref_ddr regulator, which does not have a dedicated supply, but without
>> a vref_ddr-supply property the system now no longer boots.
> [...]
>
> Can you catch debug logs for the bootup in question? I'm not sure what's
> the failure mode in your case. I guess this is not a bypassed regulator?
Boot up with v5.10-rc2 + your cf1ad559a2 ("regulator: defer probe when trying
to get voltage from unresolved supply") hangs:
[1.151489] stm32f7-i2c 40015000.i2c: STM32F7 I2C-0 bus adapter
[1.180698] stpmic1 1-0033: PMIC Chip Version: 0x10
[1.189526] vddcore: supplied by regulator-dummy
[1.195633] vdd_ddr: supplied by regulator-dummy
[1.201672] vdd: supplied by regulator-dummy
[1.207452] v3v3: supplied by 5V2
[1.211997] v1v8_audio: supplied by v3v3
[1.218036] v3v3_hdmi: supplied by 5V2
[1.223626] vtt_ddr: supplied by regulator-dummy
[1.227107] vdd_usb: supplied by regulator-dummy
[1.234532] vdda: supplied by 5V2
[1.239497] v1v2_hdmi: supplied by v3v3
Boot up with v5.10-rc2 with aea6cb99 ("regulator: resolve supply after
creating regulator") reverted boots correctly:
[1.151458] stm32f7-i2c 40015000.i2c: STM32F7 I2C-0 bus adapter
[1.180668] stpmic1 1-0033: PMIC Chip Version: 0x10
[1.186629] BUCK1: supplied by regulator-dummy
[1.192628] BUCK2: supplied by regulator-dummy
[1.198667] BUCK3: supplied by regulator-dummy
[1.204623] BUCK4: supplied by 5V2
[1.209424] LDO1: supplied by v3v3
[1.214931] LDO2: supplied by 5V2
[1.219897] LDO3: supplied by regulator-dummy
[1.225784] LDO4: supplied by regulator-dummy
[1.229239] LDO5: supplied by 5V2
[1.235097] LDO6: supplied by v3v3
[1.240164] VREF_DDR: supplied by regulator-dummy
[1.246130] BOOST: supplied by 5V2
[1.248617] VBUS_OTG: supplied by bst_out
[1.252698] SW_OUT: supplied by bst_out
Boot up with v5.10-rc2 + your cf1ad559a2 + { regulators { vref_ddr-supply
= <_5v2>; }
boots correctly as well:
[1.151531] stm32f7-i2c 40015000.i2c: STM32F7 I2C-0 bus adapter
[1.180759] stpmic1 1-0033: PMIC Chip Version: 0x10
[1.189543] vddcore: supplied by regulator-dummy
[1.195651] vdd_ddr: supplied by regulator-dummy
[1.201687] vdd: supplied by regulator-dummy
[1.207470] v3v3: supplied by 5V2
[1.212015] v1v8_audio: supplied by v3v3
[1.218053] v3v3_hdmi: supplied by 5V2
[1.223647] vtt_ddr: supplied by regulator-dummy
[1.227128] vdd_usb: supplied by regulator-dummy
[1.234553] vdda: supplied by 5V2
[1.239510] v1v2_hdmi: supplied by v3v3
[1.244932] vref_ddr: supplied by 5V2
[1.247397] bst_out: supplied by 5V2
[1.251338] vbus_otg: supplied by bst_out
[1.255416] vbus_sw: supplied by bst_out
Cheers
Ahmad
>
> Best Regards,
> Michał Mirosław
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [BUG] Error applying setting, reverse things back on lot of devices
On Mon, Nov 02, 2020 at 01:48:54PM +0100, Ahmad Fatoum wrote:
> Hello Michał,
>
> CC += linux-stm32
>
> On 10/24/20 1:53 PM, Michał Mirosław wrote:
> > On Fri, Oct 23, 2020 at 10:39:43PM +0200, Corentin Labbe wrote:
> >> On Fri, Oct 23, 2020 at 03:42:01PM +0200, Corentin Labbe wrote:
> >>> On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote:
> >>> I have just saw thoses 3 lines which are probably the real problem.
> >>> I have started a new bisect with this error, but it is hitting the same
> >>> "crash range" the first one.
> >>>
> >>
> >> I have bisected the problem to commit
> >> aea6cb99703e17019e025aa71643b4d3e0a24413 ("regulator: resolve supply after
> >> creating regulator")
> >> Reverting this fix my problem.
>
> The change broke boot on all the STM32MP1 boards, because the STPMIC driver
> has a vref_ddr regulator, which does not have a dedicated supply, but without
> a vref_ddr-supply property the system now no longer boots.
[...]
Can you catch debug logs for the bootup in question? I'm not sure what's
the failure mode in your case. I guess this is not a bypassed regulator?
Best Regards,
Michał Mirosław
Re: [BUG] Error applying setting, reverse things back on lot of devices
Hello Michał,
CC += linux-stm32
On 10/24/20 1:53 PM, Michał Mirosław wrote:
> On Fri, Oct 23, 2020 at 10:39:43PM +0200, Corentin Labbe wrote:
>> On Fri, Oct 23, 2020 at 03:42:01PM +0200, Corentin Labbe wrote:
>>> On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote:
>>> I have just saw thoses 3 lines which are probably the real problem.
>>> I have started a new bisect with this error, but it is hitting the same
>>> "crash range" the first one.
>>>
>>
>> I have bisected the problem to commit
>> aea6cb99703e17019e025aa71643b4d3e0a24413 ("regulator: resolve supply after
>> creating regulator")
>> Reverting this fix my problem.
The change broke boot on all the STM32MP1 boards, because the STPMIC driver
has a vref_ddr regulator, which does not have a dedicated supply, but without
a vref_ddr-supply property the system now no longer boots.
> Can you try the hack below?
>
> Best Regards,
> Michał Mirosław
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index a4ffd71696da..9ad091f5f1ab 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -1169,6 +1169,9 @@ static int machine_constraints_voltage(struct
> regulator_dev *rdev,
> }
>
> if (current_uV < 0) {
> + if (current_uV == -EINVAL && rdev->supply_name)
> + return -EPROBE_DEFER;
> +
This doesn't fix the issue for the STM32MP1 boards (tested on LXA MC-1).
Seeing that the patch is already in stable, I think this patch should be
reverted until the issues are solved in Linus' master.
Cheers,
Ahmad
> rdev_err(rdev,
>"failed to get the current voltage: %pe\n",
>ERR_PTR(current_uV));
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [BUG] Error applying setting, reverse things back on lot of devices
On Sun, Nov 01, 2020 at 02:31:15AM +0100, Ondřej Jirman wrote:
> Hello Michał,
>
> On Sat, Oct 24, 2020 at 01:53:07PM +0200, Michał Mirosław wrote:
> > On Fri, Oct 23, 2020 at 10:39:43PM +0200, Corentin Labbe wrote:
> > > On Fri, Oct 23, 2020 at 03:42:01PM +0200, Corentin Labbe wrote:
> > > > On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote:
> > > > > [5.796585] dcdc4: supplied by regulator-dummy
> > > > > [5.801647] vcc-dram: supplied by regulator-dummy
> > > > > [5.806470] vcc-gmac-phy: failed to get the current voltage:
> > > > > -EINVAL
> > > > > [5.812839] axp20x-regulator axp20x-regulator: Failed to register
> > > > > dc1sw
> > > > > [5.820291] axp20x-regulator: probe of axp20x-regulator failed
> > > > > with error -22
> > > >
> > > > I have just saw thoses 3 lines which are probably the real problem.
> > > > I have started a new bisect with this error, but it is hitting the same
> > > > "crash range" the first one.
> > > >
> > >
> > > I have bisected the problem to commit
> > > aea6cb99703e17019e025aa71643b4d3e0a24413 ("regulator: resolve supply
> > > after creating regulator")
> > > Reverting this fix my problem.
> >
> > Can you try the hack below?
> >
> > Best Regards,
> > Michał Mirosław
> >
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index a4ffd71696da..9ad091f5f1ab 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -1169,6 +1169,9 @@ static int machine_constraints_voltage(struct
> > regulator_dev *rdev,
> > }
> >
> > if (current_uV < 0) {
> > + if (current_uV == -EINVAL && rdev->supply_name)
> > + return -EPROBE_DEFER;
> > +
> > rdev_err(rdev,
> > "failed to get the current voltage: %pe\n",
> > ERR_PTR(current_uV));
>
> I did hit the same problem on sun8i-a83t-tbs-a711.dts tablet.
>
> The patch helps on top of v5.9.2, and on linus/master.
>
Hello
Sorry I didnt get your original email.
Tested on top of next-20201030.
I have added a debug """rdev_info(rdev, "%s DEFER\n", __func__);""" and I
confirm this hack is used since I got "vcc-gmac-phy:
machine_constraints_voltage DEFER"
So if you send the patch you can add:
Tested-by: Corentin Labbe
Tested-on: sun8i-r40-bananapi-m2-ultra
Regards
Re: [BUG] Error applying setting, reverse things back on lot of devices
Hello Michał,
On Sat, Oct 24, 2020 at 01:53:07PM +0200, Michał Mirosław wrote:
> On Fri, Oct 23, 2020 at 10:39:43PM +0200, Corentin Labbe wrote:
> > On Fri, Oct 23, 2020 at 03:42:01PM +0200, Corentin Labbe wrote:
> > > On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote:
> > > > [5.796585] dcdc4: supplied by regulator-dummy
> > > > [5.801647] vcc-dram: supplied by regulator-dummy
> > > > [5.806470] vcc-gmac-phy: failed to get the current voltage: -EINVAL
> > > > [5.812839] axp20x-regulator axp20x-regulator: Failed to register
> > > > dc1sw
> > > > [5.820291] axp20x-regulator: probe of axp20x-regulator failed with
> > > > error -22
> > >
> > > I have just saw thoses 3 lines which are probably the real problem.
> > > I have started a new bisect with this error, but it is hitting the same
> > > "crash range" the first one.
> > >
> >
> > I have bisected the problem to commit
> > aea6cb99703e17019e025aa71643b4d3e0a24413 ("regulator: resolve supply after
> > creating regulator")
> > Reverting this fix my problem.
>
> Can you try the hack below?
>
> Best Regards,
> Michał Mirosław
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index a4ffd71696da..9ad091f5f1ab 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -1169,6 +1169,9 @@ static int machine_constraints_voltage(struct
> regulator_dev *rdev,
> }
>
> if (current_uV < 0) {
> + if (current_uV == -EINVAL && rdev->supply_name)
> + return -EPROBE_DEFER;
> +
> rdev_err(rdev,
>"failed to get the current voltage: %pe\n",
>ERR_PTR(current_uV));
I did hit the same problem on sun8i-a83t-tbs-a711.dts tablet.
The patch helps on top of v5.9.2, and on linus/master.
regards,
o.
Re: [BUG] Error applying setting, reverse things back on lot of devices
On Fri, Oct 23, 2020 at 10:39:43PM +0200, Corentin Labbe wrote: > On Fri, Oct 23, 2020 at 03:42:01PM +0200, Corentin Labbe wrote: > > On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote: > > > Hello > > > > > > On next-20201016, booting my sun8i-r40-bananapi-m2-ultra, the boot end > > > without at least stmmac working. > > > [0.00] Booting Linux on physical CPU 0x0 > > > [0.00] Linux version > > > 5.9.0-next-20201016-00055-g98489213ff7c-dirty (compile@Red) > > > (armv7a-unknown-linux-gnueabihf-gcc (Gentoo 9.3.0-r1 p3) 9.3.0, GNU ld > > > (Gentoo 2.33.1 p2) 2.33.1) #162 SMP Tue Oct 20 08:10:25 CEST 2020 > > > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), > > > cr=10c5387d > > > [0.00] CPU: div instructions available: patching division code > > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > > > instruction cache > > > [0.00] OF: fdt: Machine model: Banana Pi BPI-M2-Ultra > > > [0.00] Memory policy: Data cache writealloc > > > [0.00] cma: Reserved 16 MiB at 0xbec0 > > > [0.00] Zone ranges: > > > [0.00] Normal [mem 0x4000-0x6fff] > > > [0.00] HighMem [mem 0x7000-0xbfff] > > > [0.00] Movable zone start for each node > > > [0.00] Early memory node ranges > > > [0.00] node 0: [mem 0x4000-0xbfff] > > > [0.00] Initmem setup node 0 [mem > > > 0x4000-0xbfff] > > > [0.00] psci: probing for conduit method from DT. > > > [0.00] psci: Using PSCI v0.1 Function IDs from DT > > > [0.00] percpu: Embedded 15 pages/cpu s30924 r8192 d22324 u61440 > > > [0.00] Built 1 zonelists, mobility grouping on. Total pages: > > > 522752 > > > [0.00] Kernel command line: console=ttyS0,115200n8 root=/dev/ram0 > > > ip=dhcp trace_event=initcall:*,module:* trace_options=stacktrace ip=dhcp > > > [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 > > > bytes, linear) > > > [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 > > > bytes, linear) > > > [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off > > > [0.00] Memory: 2020320K/2097152K available (7168K kernel code, > > > 934K rwdata, 2252K rodata, 1024K init, 248K bss, 60448K reserved, 16384K > > > cma-reserved, 1294324K highmem) > > > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > > > [0.00] rcu: Hierarchical RCU implementation. > > > [0.00] rcu: RCU event tracing is enabled. > > > [0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to > > > nr_cpu_ids=4. > > > [0.00] rcu: RCU calculated value of scheduler-enlistment delay is > > > 10 jiffies. > > > [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, > > > nr_cpu_ids=4 > > > [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 > > > [0.00] GIC: Using split EOI/Deactivate mode > > > [0.00] random: get_random_bytes called from > > > start_kernel+0x320/0x4ac with crng_init=0 > > > [0.00] arch_timer: cp15 timer(s) running at 24.00MHz (phys). > > > [0.00] clocksource: arch_sys_counter: mask: 0xff > > > max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns > > > [0.07] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps > > > every 4398046511097ns > > > [0.20] Switching to timer-based delay loop, resolution 41ns > > > [0.000176] Console: colour dummy device 80x30 > > > [0.000230] Calibrating delay loop (skipped), value calculated using > > > timer frequency.. 48.00 BogoMIPS (lpj=24) > > > [0.000251] pid_max: default: 32768 minimum: 301 > > > [0.000395] Mount-cache hash table entries: 2048 (order: 1, 8192 > > > bytes, linear) > > > [0.000414] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 > > > bytes, linear) > > > [0.001117] CPU: Testing write buffer coherency: ok > > > [0.001420] /cpus/cpu@0 missing clock-frequency property > > > [0.001442] /cpus/cpu@1 missing clock-frequency property > > > [0.001459] /cpus/cpu@2 missing clock-frequency property > > > [0.001477] /cpus/cpu@3 missing clock-frequency property > > > [0.001490] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 > > > [0.002001] Setting up static identity map for 0x4010 - 0x40100060 > > > [0.002119] rcu: Hierarchical SRCU implementation. > > > [0.002580] smp: Bringing up secondary CPUs ... > > > [0.013271] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 > > > [0.024063] CPU2: thread -1, cpu 2, socket 0, mpidr 8002 > > > [0.034784] CPU3: thread -1, cpu 3, socket 0, mpidr 8003 > > > [0.034880] smp: Brought up 1 node, 4 CPUs > > > [0.034904] SMP: Total of 4 processors activated (192.00 BogoMIPS). > > > [0.034912] CPU: All CPU(s)
Re: [BUG] Error applying setting, reverse things back on lot of devices
On Fri, Oct 23, 2020 at 10:39:43PM +0200, Corentin Labbe wrote: > On Fri, Oct 23, 2020 at 03:42:01PM +0200, Corentin Labbe wrote: > > On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote: > > > Hello > > > > > > On next-20201016, booting my sun8i-r40-bananapi-m2-ultra, the boot end > > > without at least stmmac working. > > > [0.00] Booting Linux on physical CPU 0x0 > > > [0.00] Linux version > > > 5.9.0-next-20201016-00055-g98489213ff7c-dirty (compile@Red) > > > (armv7a-unknown-linux-gnueabihf-gcc (Gentoo 9.3.0-r1 p3) 9.3.0, GNU ld > > > (Gentoo 2.33.1 p2) 2.33.1) #162 SMP Tue Oct 20 08:10:25 CEST 2020 > > > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), > > > cr=10c5387d > > > [0.00] CPU: div instructions available: patching division code > > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > > > instruction cache > > > [0.00] OF: fdt: Machine model: Banana Pi BPI-M2-Ultra > > > [0.00] Memory policy: Data cache writealloc > > > [0.00] cma: Reserved 16 MiB at 0xbec0 > > > [0.00] Zone ranges: > > > [0.00] Normal [mem 0x4000-0x6fff] > > > [0.00] HighMem [mem 0x7000-0xbfff] > > > [0.00] Movable zone start for each node > > > [0.00] Early memory node ranges > > > [0.00] node 0: [mem 0x4000-0xbfff] > > > [0.00] Initmem setup node 0 [mem > > > 0x4000-0xbfff] > > > [0.00] psci: probing for conduit method from DT. > > > [0.00] psci: Using PSCI v0.1 Function IDs from DT > > > [0.00] percpu: Embedded 15 pages/cpu s30924 r8192 d22324 u61440 > > > [0.00] Built 1 zonelists, mobility grouping on. Total pages: > > > 522752 > > > [0.00] Kernel command line: console=ttyS0,115200n8 root=/dev/ram0 > > > ip=dhcp trace_event=initcall:*,module:* trace_options=stacktrace ip=dhcp > > > [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 > > > bytes, linear) > > > [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 > > > bytes, linear) > > > [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off > > > [0.00] Memory: 2020320K/2097152K available (7168K kernel code, > > > 934K rwdata, 2252K rodata, 1024K init, 248K bss, 60448K reserved, 16384K > > > cma-reserved, 1294324K highmem) > > > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > > > [0.00] rcu: Hierarchical RCU implementation. > > > [0.00] rcu: RCU event tracing is enabled. > > > [0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to > > > nr_cpu_ids=4. > > > [0.00] rcu: RCU calculated value of scheduler-enlistment delay is > > > 10 jiffies. > > > [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, > > > nr_cpu_ids=4 > > > [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 > > > [0.00] GIC: Using split EOI/Deactivate mode > > > [0.00] random: get_random_bytes called from > > > start_kernel+0x320/0x4ac with crng_init=0 > > > [0.00] arch_timer: cp15 timer(s) running at 24.00MHz (phys). > > > [0.00] clocksource: arch_sys_counter: mask: 0xff > > > max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns > > > [0.07] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps > > > every 4398046511097ns > > > [0.20] Switching to timer-based delay loop, resolution 41ns > > > [0.000176] Console: colour dummy device 80x30 > > > [0.000230] Calibrating delay loop (skipped), value calculated using > > > timer frequency.. 48.00 BogoMIPS (lpj=24) > > > [0.000251] pid_max: default: 32768 minimum: 301 > > > [0.000395] Mount-cache hash table entries: 2048 (order: 1, 8192 > > > bytes, linear) > > > [0.000414] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 > > > bytes, linear) > > > [0.001117] CPU: Testing write buffer coherency: ok > > > [0.001420] /cpus/cpu@0 missing clock-frequency property > > > [0.001442] /cpus/cpu@1 missing clock-frequency property > > > [0.001459] /cpus/cpu@2 missing clock-frequency property > > > [0.001477] /cpus/cpu@3 missing clock-frequency property > > > [0.001490] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 > > > [0.002001] Setting up static identity map for 0x4010 - 0x40100060 > > > [0.002119] rcu: Hierarchical SRCU implementation. > > > [0.002580] smp: Bringing up secondary CPUs ... > > > [0.013271] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 > > > [0.024063] CPU2: thread -1, cpu 2, socket 0, mpidr 8002 > > > [0.034784] CPU3: thread -1, cpu 3, socket 0, mpidr 8003 > > > [0.034880] smp: Brought up 1 node, 4 CPUs > > > [0.034904] SMP: Total of 4 processors activated (192.00 BogoMIPS). > > > [0.034912] CPU: All CPU(s)
Re: [BUG] Error applying setting, reverse things back on lot of devices
On Fri, Oct 23, 2020 at 03:42:01PM +0200, Corentin Labbe wrote: > On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote: > > Hello > > > > On next-20201016, booting my sun8i-r40-bananapi-m2-ultra, the boot end > > without at least stmmac working. > > [0.00] Booting Linux on physical CPU 0x0 > > [0.00] Linux version 5.9.0-next-20201016-00055-g98489213ff7c-dirty > > (compile@Red) (armv7a-unknown-linux-gnueabihf-gcc (Gentoo 9.3.0-r1 p3) > > 9.3.0, GNU ld (Gentoo 2.33.1 p2) 2.33.1) #162 SMP Tue Oct 20 08:10:25 CEST > > 2020 > > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), > > cr=10c5387d > > [0.00] CPU: div instructions available: patching division code > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > > instruction cache > > [0.00] OF: fdt: Machine model: Banana Pi BPI-M2-Ultra > > [0.00] Memory policy: Data cache writealloc > > [0.00] cma: Reserved 16 MiB at 0xbec0 > > [0.00] Zone ranges: > > [0.00] Normal [mem 0x4000-0x6fff] > > [0.00] HighMem [mem 0x7000-0xbfff] > > [0.00] Movable zone start for each node > > [0.00] Early memory node ranges > > [0.00] node 0: [mem 0x4000-0xbfff] > > [0.00] Initmem setup node 0 [mem > > 0x4000-0xbfff] > > [0.00] psci: probing for conduit method from DT. > > [0.00] psci: Using PSCI v0.1 Function IDs from DT > > [0.00] percpu: Embedded 15 pages/cpu s30924 r8192 d22324 u61440 > > [0.00] Built 1 zonelists, mobility grouping on. Total pages: 522752 > > [0.00] Kernel command line: console=ttyS0,115200n8 root=/dev/ram0 > > ip=dhcp trace_event=initcall:*,module:* trace_options=stacktrace ip=dhcp > > [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 > > bytes, linear) > > [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 > > bytes, linear) > > [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off > > [0.00] Memory: 2020320K/2097152K available (7168K kernel code, 934K > > rwdata, 2252K rodata, 1024K init, 248K bss, 60448K reserved, 16384K > > cma-reserved, 1294324K highmem) > > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > > [0.00] rcu: Hierarchical RCU implementation. > > [0.00] rcu: RCU event tracing is enabled. > > [0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to > > nr_cpu_ids=4. > > [0.00] rcu: RCU calculated value of scheduler-enlistment delay is > > 10 jiffies. > > [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 > > [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 > > [0.00] GIC: Using split EOI/Deactivate mode > > [0.00] random: get_random_bytes called from > > start_kernel+0x320/0x4ac with crng_init=0 > > [0.00] arch_timer: cp15 timer(s) running at 24.00MHz (phys). > > [0.00] clocksource: arch_sys_counter: mask: 0xff > > max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns > > [0.07] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every > > 4398046511097ns > > [0.20] Switching to timer-based delay loop, resolution 41ns > > [0.000176] Console: colour dummy device 80x30 > > [0.000230] Calibrating delay loop (skipped), value calculated using > > timer frequency.. 48.00 BogoMIPS (lpj=24) > > [0.000251] pid_max: default: 32768 minimum: 301 > > [0.000395] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, > > linear) > > [0.000414] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 > > bytes, linear) > > [0.001117] CPU: Testing write buffer coherency: ok > > [0.001420] /cpus/cpu@0 missing clock-frequency property > > [0.001442] /cpus/cpu@1 missing clock-frequency property > > [0.001459] /cpus/cpu@2 missing clock-frequency property > > [0.001477] /cpus/cpu@3 missing clock-frequency property > > [0.001490] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 > > [0.002001] Setting up static identity map for 0x4010 - 0x40100060 > > [0.002119] rcu: Hierarchical SRCU implementation. > > [0.002580] smp: Bringing up secondary CPUs ... > > [0.013271] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 > > [0.024063] CPU2: thread -1, cpu 2, socket 0, mpidr 8002 > > [0.034784] CPU3: thread -1, cpu 3, socket 0, mpidr 8003 > > [0.034880] smp: Brought up 1 node, 4 CPUs > > [0.034904] SMP: Total of 4 processors activated (192.00 BogoMIPS). > > [0.034912] CPU: All CPU(s) started in HYP mode. > > [0.034919] CPU: Virtualization extensions available. > > [0.035754] devtmpfs: initialized > > [0.041021] VFP support v0.3: implementor 41 architecture 2 part 30 > > variant 7 rev 5 > > [0.041258]
Re: [BUG] Error applying setting, reverse things back on lot of devices
On Wed, Oct 21, 2020 at 08:31:49PM +0200, Corentin Labbe wrote: > Hello > > On next-20201016, booting my sun8i-r40-bananapi-m2-ultra, the boot end > without at least stmmac working. > [0.00] Booting Linux on physical CPU 0x0 > [0.00] Linux version 5.9.0-next-20201016-00055-g98489213ff7c-dirty > (compile@Red) (armv7a-unknown-linux-gnueabihf-gcc (Gentoo 9.3.0-r1 p3) 9.3.0, > GNU ld (Gentoo 2.33.1 p2) 2.33.1) #162 SMP Tue Oct 20 08:10:25 CEST 2020 > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d > [0.00] CPU: div instructions available: patching division code > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > instruction cache > [0.00] OF: fdt: Machine model: Banana Pi BPI-M2-Ultra > [0.00] Memory policy: Data cache writealloc > [0.00] cma: Reserved 16 MiB at 0xbec0 > [0.00] Zone ranges: > [0.00] Normal [mem 0x4000-0x6fff] > [0.00] HighMem [mem 0x7000-0xbfff] > [0.00] Movable zone start for each node > [0.00] Early memory node ranges > [0.00] node 0: [mem 0x4000-0xbfff] > [0.00] Initmem setup node 0 [mem > 0x4000-0xbfff] > [0.00] psci: probing for conduit method from DT. > [0.00] psci: Using PSCI v0.1 Function IDs from DT > [0.00] percpu: Embedded 15 pages/cpu s30924 r8192 d22324 u61440 > [0.00] Built 1 zonelists, mobility grouping on. Total pages: 522752 > [0.00] Kernel command line: console=ttyS0,115200n8 root=/dev/ram0 > ip=dhcp trace_event=initcall:*,module:* trace_options=stacktrace ip=dhcp > [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 > bytes, linear) > [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, > linear) > [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off > [0.00] Memory: 2020320K/2097152K available (7168K kernel code, 934K > rwdata, 2252K rodata, 1024K init, 248K bss, 60448K reserved, 16384K > cma-reserved, 1294324K highmem) > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > [0.00] rcu: Hierarchical RCU implementation. > [0.00] rcu: RCU event tracing is enabled. > [0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4. > [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 10 > jiffies. > [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 > [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 > [0.00] GIC: Using split EOI/Deactivate mode > [0.00] random: get_random_bytes called from start_kernel+0x320/0x4ac > with crng_init=0 > [0.00] arch_timer: cp15 timer(s) running at 24.00MHz (phys). > [0.00] clocksource: arch_sys_counter: mask: 0xff > max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns > [0.07] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every > 4398046511097ns > [0.20] Switching to timer-based delay loop, resolution 41ns > [0.000176] Console: colour dummy device 80x30 > [0.000230] Calibrating delay loop (skipped), value calculated using timer > frequency.. 48.00 BogoMIPS (lpj=24) > [0.000251] pid_max: default: 32768 minimum: 301 > [0.000395] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, > linear) > [0.000414] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 > bytes, linear) > [0.001117] CPU: Testing write buffer coherency: ok > [0.001420] /cpus/cpu@0 missing clock-frequency property > [0.001442] /cpus/cpu@1 missing clock-frequency property > [0.001459] /cpus/cpu@2 missing clock-frequency property > [0.001477] /cpus/cpu@3 missing clock-frequency property > [0.001490] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 > [0.002001] Setting up static identity map for 0x4010 - 0x40100060 > [0.002119] rcu: Hierarchical SRCU implementation. > [0.002580] smp: Bringing up secondary CPUs ... > [0.013271] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 > [0.024063] CPU2: thread -1, cpu 2, socket 0, mpidr 8002 > [0.034784] CPU3: thread -1, cpu 3, socket 0, mpidr 8003 > [0.034880] smp: Brought up 1 node, 4 CPUs > [0.034904] SMP: Total of 4 processors activated (192.00 BogoMIPS). > [0.034912] CPU: All CPU(s) started in HYP mode. > [0.034919] CPU: Virtualization extensions available. > [0.035754] devtmpfs: initialized > [0.041021] VFP support v0.3: implementor 41 architecture 2 part 30 > variant 7 rev 5 > [0.041258] clocksource: jiffies: mask: 0x max_cycles: 0x, > max_idle_ns: 1911260446275 ns > [0.041283] futex hash table entries: 1024 (order: 4, 65536 bytes, linear) > [0.042026] pinctrl core: initialized pinctrl subsystem > [0.043049] NET:
[BUG] Error applying setting, reverse things back on lot of devices
Hello On next-20201016, booting my sun8i-r40-bananapi-m2-ultra, the boot end without at least stmmac working. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 5.9.0-next-20201016-00055-g98489213ff7c-dirty (compile@Red) (armv7a-unknown-linux-gnueabihf-gcc (Gentoo 9.3.0-r1 p3) 9.3.0, GNU ld (Gentoo 2.33.1 p2) 2.33.1) #162 SMP Tue Oct 20 08:10:25 CEST 2020 [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: Banana Pi BPI-M2-Ultra [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 16 MiB at 0xbec0 [0.00] Zone ranges: [0.00] Normal [mem 0x4000-0x6fff] [0.00] HighMem [mem 0x7000-0xbfff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x4000-0xbfff] [0.00] Initmem setup node 0 [mem 0x4000-0xbfff] [0.00] psci: probing for conduit method from DT. [0.00] psci: Using PSCI v0.1 Function IDs from DT [0.00] percpu: Embedded 15 pages/cpu s30924 r8192 d22324 u61440 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 522752 [0.00] Kernel command line: console=ttyS0,115200n8 root=/dev/ram0 ip=dhcp trace_event=initcall:*,module:* trace_options=stacktrace ip=dhcp [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] Memory: 2020320K/2097152K available (7168K kernel code, 934K rwdata, 2252K rodata, 1024K init, 248K bss, 60448K reserved, 16384K cma-reserved, 1294324K highmem) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] rcu: Hierarchical RCU implementation. [0.00] rcu: RCU event tracing is enabled. [0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4. [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] GIC: Using split EOI/Deactivate mode [0.00] random: get_random_bytes called from start_kernel+0x320/0x4ac with crng_init=0 [0.00] arch_timer: cp15 timer(s) running at 24.00MHz (phys). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns [0.07] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns [0.20] Switching to timer-based delay loop, resolution 41ns [0.000176] Console: colour dummy device 80x30 [0.000230] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=24) [0.000251] pid_max: default: 32768 minimum: 301 [0.000395] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear) [0.000414] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear) [0.001117] CPU: Testing write buffer coherency: ok [0.001420] /cpus/cpu@0 missing clock-frequency property [0.001442] /cpus/cpu@1 missing clock-frequency property [0.001459] /cpus/cpu@2 missing clock-frequency property [0.001477] /cpus/cpu@3 missing clock-frequency property [0.001490] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.002001] Setting up static identity map for 0x4010 - 0x40100060 [0.002119] rcu: Hierarchical SRCU implementation. [0.002580] smp: Bringing up secondary CPUs ... [0.013271] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 [0.024063] CPU2: thread -1, cpu 2, socket 0, mpidr 8002 [0.034784] CPU3: thread -1, cpu 3, socket 0, mpidr 8003 [0.034880] smp: Brought up 1 node, 4 CPUs [0.034904] SMP: Total of 4 processors activated (192.00 BogoMIPS). [0.034912] CPU: All CPU(s) started in HYP mode. [0.034919] CPU: Virtualization extensions available. [0.035754] devtmpfs: initialized [0.041021] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5 [0.041258] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.041283] futex hash table entries: 1024 (order: 4, 65536 bytes, linear) [0.042026] pinctrl core: initialized pinctrl subsystem [0.043049] NET: Registered protocol family 16 [0.044324] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.045360] thermal_sys: Registered thermal governor 'step_wise' [0.045788] hw-breakpoint: found 5 (+1 reserved)
