[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7hy42ahihe.fsf@baylibre.com>
Date: Thu, 29 Sep 2016 07:46:05 -0700
From: Kevin Hilman <khilman@...libre.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: "kernelci.org bot" <bot@...nelci.org>,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, linux@...ck-us.net,
shuah.kh@...sung.com, patches@...nelci.org,
ben.hutchings@...ethink.co.uk, stable@...r.kernel.org
Subject: Re: [PATCH 4.7 00/69] 4.7.6-stable review
Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:
> On Thu, Sep 29, 2016 at 01:22:06AM -0700, Kevin Hilman wrote:
>> kernelci.org bot <bot@...nelci.org> writes:
>>
>> > stable-rc boot: 105 boots: 1 failed, 100 passed with 4 offline (v4.7.5-70-g64e4c0f6d4b1)
>> >
>> > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.7.5-70-g64e4c0f6d4b1/
>> > Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.7.5-70-g64e4c0f6d4b1/
>> >
>> > Tree: stable-rc
>> > Branch: local/linux-4.7.y
>> > Git Describe: v4.7.5-70-g64e4c0f6d4b1
>> > Git Commit: 64e4c0f6d4b12abd1966ac9ad2082a0815a3d0eb
>> > Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> > Tested: 32 unique boards, 12 SoC families, 20 builds out of 205
>> >
>> > Boot Failure Detected: https://kernelci.org/boot/?v4.7.5-70-g64e4c0f6d4b1&fail
>> >
>> > arm:
>> >
>> > multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>> > at91-sama5d3_xplained: 1 failed lab
>>
>> This looks like a legit new failure, and the same thing is happening on
>> stable-rc/linux-4.4.y.
>>
>> I've asked the lab with this board to have a closer look,
>
> Thanks, I don't see anything obvious in the patch series that would have
> affected this board, but given the PROVE_LOCKING option, maybe it was a
> more generic change that is causing the issue.
Since the kernelci email report went out, another lab reported a PASS
for this board on the same defconfig, so this particular FAIL is likely
a lab-specific issue, so I wouldn't let this block stable release.
FYI... I have a few other boards[1] that are failing in mainline with
CONFIG_PROVE_LOCKING=y, and I've yet to get to the root of the problem.
My best guess currently is that those seem to be related to the
bootloader/boot-firmware not being able to deal with large zImage
(CONFIG_PROVE_LOCKING makes a bit bigger image.)
I don't know the closed bootloader/boot-firmware on these qualcomm
platforms, so I've asked the qcom maintainers for some help.
Kevin
[1] https://kernelci.org/boot/all/job/mainline/kernel/v4.8-rc8-13-g53061afee43b/
Powered by blists - more mailing lists