Re: [PATCH 4.9 000/116] 4.9.2-stable review

[Kevin Hilman]

Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes:

> On Fri, Jan 06, 2017 at 09:42:24PM -0800, kernelci.org bot wrote:
>> stable-rc boot: 513 boots: 4 failed, 489 passed with 20 offline (v4.9.1-117-ge3bc65e52a08)
>> 
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.9.1-117-ge3bc65e52a08/
>> Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.9.1-117-ge3bc65e52a08/
>> 
>> Tree: stable-rc
>> Branch: local/linux-4.9.y
>> Git Describe: v4.9.1-117-ge3bc65e52a08
>> Git Commit: e3bc65e52a086ea9bcc31605737bbf0476f9bcd3
>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> Tested: 88 unique boards, 25 SoC families, 35 builds out of 206
>> 
>> Boot Regressions Detected:
>> 
>> arm:
>> 
>>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>>         vexpress-v2p-ca15_a7:
>>             lab-broonie: new failure (last pass: v4.9.1)
>> 
>> Boot Failures Detected:
>> 
>> arm:
>> 
>>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
>>         vexpress-v2p-ca15_a7: 1 failed lab
>> 
>>     sunxi_defconfig
>>         sun4i-a10-cubieboard: 1 failed lab
>> 
>>     exynos_defconfig
>>         exynos5422-odroidxu3_rootfs:nfs: 1 failed lab
>> 
>> arm64:
>> 
>>     defconfig+CONFIG_CPU_BIG_ENDIAN=y
>>         juno-r2: 1 failed lab
>
> Are all of these really "failures"?  Some of them seem like they really
> did boot, but the test system didn't detect it?
>
> I don't know what to do with these reports, should I trust them that I
> broke something, or just ignore them and let someone else dig into them
> to determine if it's a false-positive or something like that?

Until we get these more reliable, you can assume that I'll flag
something that's really a blocker.

Only the exynos5422-odroidxu3 failure is a true failure which is also
happendin in mainline. It's been reported and fixed.

The others are silly lab/hardware issues that are hard to get
stabilized. e.g. QEMU taking a really long time to boot
CONFIG_PROVE_LOCKING=y kernels, flaky USB-UART cables etc.

Kevin