[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170919055037.GH3349@codeaurora.org>
Date: Mon, 18 Sep 2017 22:50:37 -0700
From: Stephen Boyd <sboyd@...eaurora.org>
To: Kevin Hilman <khilman@...libre.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"kernelci.org bot" <bot@...nelci.org>,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, linux@...ck-us.net,
shuahkh@....samsung.com, patches@...nelci.org,
ben.hutchings@...ethink.co.uk, stable@...r.kernel.org,
andy.gross@...aro.org
Subject: Re: [PATCH 4.4 00/31] 4.4.88-stable review
On 09/13, Kevin Hilman wrote:
> Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:
>
> > On Tue, Sep 12, 2017 at 03:57:50PM -0700, kernelci.org bot wrote:
> >> stable-rc/linux-4.4.y boot: 450 boots: 1 failed, 446 passed with 3 offline (v4.4.87-32-gb8c205d85576)
> >>
> >> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.87-32-gb8c205d85576/
> >> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.87-32-gb8c205d85576/
> >>
> >> Tree: stable-rc
> >> Branch: linux-4.4.y
> >> Git Describe: v4.4.87-32-gb8c205d85576
> >> Git Commit: b8c205d855764e3db05a17ab4d03a19a5d609bdd
> >> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >> Tested: 68 unique boards, 21 SoC families, 34 builds out of 203
> >>
> >> Boot Regressions Detected:
> >>
> >> arm:
> >>
> >> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> >> qcom-apq8064-cm-qs600:
> >> lab-baylibre-seattle: new failure (last pass: v4.4.85-16-gcd99a4f3f43b)
> >
> > Is this a real failure?
>
> I tried to boot this a few more times, and it's still failing so it
> apprears it's a new regression.
>
> Added qcom maintainenrs to Cc to see if they have any ideas.
>
> These failures with CONFIG_PROVE_LOCKING seem to be more often related
> to bootloader issues with kernel size than actual CONFIG_PROVE_LOCKING,
> so I'm note exactly sure which is which here.
>
Usually when the kernel becomes too large we don't see any output
on the console at all. That's because the decompressor overwrites
something like the dtb or the initrd when it uncompresses the
kernel and then serial console can't be found. In this case, it
looks like it booted up and then got stuck when trying to run
/init from the ramdisk? Or maybe it got stuck in some interrupt
storm with mmc? There are some regulator warnings that seem to be
ignored earlier for the mmc.
[ 2.252965] s4: voltage operation not allowed
[ 2.258505] mmci-pl18x 12400000.sdcc: Voltage switch failed
No idea if that forebodes doom though.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Powered by blists - more mailing lists