next/master boot: 138 boots: 8 failed, 112 passed with 18 offline (next-20180619)

next/master boot: 138 boots: 8 failed, 112 passed with 18 offline (next-20180619)

[Mark Brown]

On Tue, Jun 19, 2018 at 07:00:13AM -0700, kernelci.org bot wrote:

Today and yesterday's -next is failing to boot on rk3399-firefly in two
configs:

>     defconfig:
>         rk3399-firefly:
>             lab-baylibre-seattle: failing since 1 day (last pass: next-20180615 - first fail: next-20180618)

>     defconfig+CONFIG_RANDOMIZE_BASE=y:
>         rk3399-firefly:
>             lab-baylibre-seattle: failing since 1 day (last pass: next-20180615 - first fail: next-20180618)

The log ends with:

[    2.629278] SWITCH_REG2: supplied by vcc3v3_sys
[    2.633030] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
[    2.633723] fan53555-reg: supplied by vcc_sys
[    2.6353|] Internal error: undefined instruction: 0 [#1] PREEMPT SMP

which is rather entertaining. 

The pending fixes -next branch is fine.  More diagnostics can be seen
at:

	https://kernelci.org/boot/id/5b28eadb59b514636d79a877/

(that's the defconfig.)  Other boards don't seem to be affected, there's
some other boards that are failing but don't seem to be related.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180619/0dbabfd4/attachment.sig>

next/master boot: 138 boots: 8 failed, 112 passed with 18 offline (next-20180619)

[Sudeep Holla]

On 19/06/18 15:13, Mark Brown wrote:
> On Tue, Jun 19, 2018 at 07:00:13AM -0700, kernelci.org bot wrote:
> 
> Today and yesterday's -next is failing to boot on rk3399-firefly in two
> configs:
> 
>>     defconfig:
>>         rk3399-firefly:
>>             lab-baylibre-seattle: failing since 1 day (last pass: next-20180615 - first fail: next-20180618)
> 
>>     defconfig+CONFIG_RANDOMIZE_BASE=y:
>>         rk3399-firefly:
>>             lab-baylibre-seattle: failing since 1 day (last pass: next-20180615 - first fail: next-20180618)
> 
> The log ends with:
> 
> [    2.629278] SWITCH_REG2: supplied by vcc3v3_sys
> [    2.633030] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
> [    2.633723] fan53555-reg: supplied by vcc_sys
> [    2.6353|] Internal error: undefined instruction: 0 [#1] PREEMPT SMP
> 
> which is rather entertaining. 
> 

Based on the logs from successful boots, I see it's CPUFreq that gets
probed after fan53555-reg. I also see that it warns about unlisted OPPs
in the successful boots. I guess, the undefined instruction could occur
if there's issue with CPU DVFS(under voltage or frequency that's not
supported). I don't have much knowledge on the platform, I am just
guessing on the possible cause here.

-- 
Regards,
Sudeep

next/master boot: 138 boots: 8 failed, 112 passed with 18 offline (next-20180619)

[Mark Brown]

On Tue, Jun 19, 2018 at 03:22:47PM +0100, Sudeep Holla wrote:

> Based on the logs from successful boots, I see it's CPUFreq that gets
> probed after fan53555-reg. I also see that it warns about unlisted OPPs
> in the successful boots. I guess, the undefined instruction could occur
> if there's issue with CPU DVFS(under voltage or frequency that's not
> supported). I don't have much knowledge on the platform, I am just
> guessing on the possible cause here.

Yeah, that was my guess - either an out of spec voltage/frequency was
selected or the regulator isn't able to keep up with the voltage
transition or a load spike and the power browns out.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180619/cd40b399/attachment.sig>

next/master boot: 138 boots: 8 failed, 112 passed with 18 offline (next-20180619)

[Heiko Stübner]

> > On Tue, Jun 19, 2018 at 07:00:13AM -0700, kernelci.org bot wrote:
> > 
> > Today and yesterday's -next is failing to boot on rk3399-firefly in two
> > 
> > configs:
> >>     defconfig:
> >>         rk3399-firefly:
> >>             lab-baylibre-seattle: failing since 1 day (last pass:
> >>             next-20180615 - first fail: next-20180618)>>     
> >>     defconfig+CONFIG_RANDOMIZE_BASE=y:
> >>         rk3399-firefly:
> >>             lab-baylibre-seattle: failing since 1 day (last pass:
> >>             next-20180615 - first fail: next-20180618)> 
> > The log ends with:
> > 
> > [    2.629278] SWITCH_REG2: supplied by vcc3v3_sys
> > [    2.633030] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1]
> > Detected! [    2.633723] fan53555-reg: supplied by vcc_sys
> > [    2.6353|] Internal error: undefined instruction: 0 [#1] PREEMPT SMP
> > 
> > which is rather entertaining.

> Am Dienstag, 19. Juni 2018, 16:41:43 CEST schrieb Mark Brown:
> On Tue, Jun 19, 2018 at 03:22:47PM +0100, Sudeep Holla wrote:
> > Based on the logs from successful boots, I see it's CPUFreq that gets
> > probed after fan53555-reg. I also see that it warns about unlisted OPPs
> > in the successful boots. I guess, the undefined instruction could occur
> > if there's issue with CPU DVFS(under voltage or frequency that's not
> > supported). I don't have much knowledge on the platform, I am just
> > guessing on the possible cause here.
> 
> Yeah, that was my guess - either an out of spec voltage/frequency was
> selected or the regulator isn't able to keep up with the voltage
> transition or a load spike and the power browns out.

I guess this is related to
	arm64: dts: rockchip: correct voltage selector Firefly-RK3399 [0]

which is in so far interesting as the patch seems to fix a similar issue
to the above with the opposite "fcs,suspend-voltage-selector" value.
And also claims to be in line with the vendor kernel.

>From looking at the schematics, we might have a discrepancy between the
fcs,suspend-voltage-selector and vsel input-pin leading to a gpio
[likely depending on what the bootloader set this pin up for].

I'll drop the patch for now and get in contact with the patch submitter.


Heiko

[0] https://patchwork.kernel.org/patch/10447075/