[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170110101738.GA3888@kroah.com>
Date: Tue, 10 Jan 2017 11:17:38 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Kevin Hilman <khilman@...libre.com>
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.9 000/116] 4.9.2-stable review
On Mon, Jan 09, 2017 at 10:19:31AM -0800, Kevin Hilman wrote:
> Greg Kroah-Hartman <gregkh@...uxfoundation.org> 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.
Ok, thanks for that, it makes my life easier in trying to parse these
reports :)
greg k-h
Powered by blists - more mailing lists