On Tue, Oct 10, 2017 at 05:33:04PM +0200, Greg Kroah-Hartman wrote: > On Tue, Oct 10, 2017 at 10:23:43AM -0500, Tom Gall wrote: > > On Tue, Oct 10, 2017 at 2:11 AM, Greg Kroah-Hartman > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote: > > >> On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman > > >> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > >> >> kernel: 4.9.54-rc1 > > >> >> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > >> >> git branch: linux-4.9.y > > >> >> git commit: 1852eae92c460813692808234da35d142a405ab7 > > >> >> git describe: v4.9.53 > > >> >> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53 > > >> > > >> >> > > >> >> No regressions (compared to build v4.9.52-65-gaceea42c68d9) > > >> > > > >> > How did your arm64 test build? There was a build regression in the -rc1 > > >> > release, are you sure you actually ran the correct image? > > >> > > >> So the header in that report was wrong. That's a c/n/p error on my > > >> part. I was in a rush to get you data before I was going to be gone > > >> for the day on Sat and wanting to get what we had into your hands > > >> before the Sunday deadline. > > >> > > >> The test results was for the RC as of commit > > >> 0e59436504287cddb9663857ae69c100b55f5e85 > > >> > > >> If you want to see the 'ugly' raw data it's all here : > > >> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/ > > > > > > I still don't understand. That _build_ should have failed, how did it > > > succeed enough to actually run the tests at all? > > > > Looks like it's because we don't build with CONFIG_KASAN. > > Ick, not good, why not? Surely you enable all of the options you can > for your hardware, right? And enabling stuff like this is good no > matter what... > FWIW, I don't enable CONFIG_KASAN or my qemu test runs either, simply because enabling it makes images all but impossible to run in qemu. Whatever KASAN does, it seems to completely defeat qemu. > > In the case where the build fails, the system won't run tests since there's no > > image to run. Likewise if we have a situation where the build fails > > for some arches > > but not all we'll only get partial test results for the builds that > > succeeded and > > likewise nothing for what failed. > > Ok, good (odd line-wrapping, did I give you too many '\n'?) > > > The results reported were based on commit id > > 0e59436504287cddb9663857ae69c100b55f5e85 > > > > Unfortunately that commit id doesn't exist anymore since it was > > replaced by the 4.9.54 release which was commit ID > > f37eb7b586f1dd24a86c50278c65322fc6787722 > > > > (and yes the release test results == rc test results that were reported) > > > > Things get a little confusing when one can't go back and compare > > commit ids. Losing history kinda sucks. > > > > I've thought about some other way to uniquely tie results to an rc > > patch maybe working > > off of : https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/ > > > > But like in this instance if there isn't both the rc1 and rc2 for > > posterity it wouldn't help. > > Least for now we have commit ids, git describe and kernel version from > > the Makefile. > > > > Why wasn't there an rc2 patch file? > > There was, I announced it. But oh, look, I never pushed it out to > kernel.org, my fault. I guess no one actually tested it except me :) > Hmm, I am pretty sure that my builders picked it up from the git repo since the previously failing builds started to pass. Guenter