On 16/11/17 14:42, Guillaume Tucker wrote:
On 15/11/17 11:13, kernelci.org bot wrote:
next/master boot: 210 boots: 35 failed, 174 passed with 1 conflict (next-20171115)
Full Boot Summary: https://kernelci.org/boot/all/job/next/branch/master/kernel/next-20171115/ Full Build Summary: https://kernelci.org/build/next/branch/master/kernel/next-20171115/
Tree: next Branch: master Git Describe: next-20171115 Git Commit: 63fb091c80188ec51f53514d07de907c1dd3d61d Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 35 unique boards, 16 SoC families, 30 builds out of 213
Boot Regressions Detected:
arm:
[...]
multi_v7_defconfig: tegra124-nyan-big: lab-collabora: failing since 11 days (last pass: next-20171102 - first fail: next-20171103)I've run another automated bisection with some tweaks to remove known failures and found this breaking change:
commit 859eb05676f67d4960130dff36d3368006716110 Author: Shawn Nematbakhsh shawnn@chromium.org Date: Fri Sep 8 13:50:11 2017 -0700
platform/chrome: Use proper protocol transfer function
Should have added, this is essentially the kernel error:
[ 1.711581] kernel BUG at drivers/platform/chrome/cros_ec_proto.c:34! [ 1.718004] Internal error: Oops - BUG: 0 [#1] SMP ARM
Please see the links to the LAVA jobs below for the full logs.
The bisection was run with CONFIG_MODULES and CONFIG_DRM_NOUVEAU disabled and d89e2378a97fafdc74cbf997e7c88af75b81610a ("drivers: flag buses which demand DMA configuration") reverted in each iteration as these things are known to cause other boot failures. See the full log here (from staging.kernelci.org Jenkins):
https://people.collabora.com/~gtucker/kernelci/bisections/20171116-nyan-big-...
As the kernelci.org automated bisection tool is still experimental, I then did a couple of checks to confirm whether this commit was still an issue:
859eb056 with MODULES and DRM_NOUVEAU disabled, failed: https://lava.collabora.co.uk/scheduler/job/992002
same as above but with 859eb056 reverted in-place, passes: https://lava.collabora.co.uk/scheduler/job/992003
next-20171115 with MODULES and DRM_NOUVEAU disabled, and d89e2378 reverted, fails: https://lava.collabora.co.uk/scheduler/job/992004
same as above but with 859eb056 reverted on top, passes: https://lava.collabora.co.uk/scheduler/job/992005
So this shows the commit found by the bisection seems to be still causing problems on tegra124-nyan-big. I haven't investigated any further, I don't know if other platforms show the same symptoms. At least this should narrow things down a bit.
Note: With this in mind, another possible bisection would be to enable DRM_NOUVEAU again while reverting the 2 known breaking commits and try to find what is actually causing the issue in that driver. I'm not planning to do this right now though...
Hope this helps!
Guillaume
For more info write to info@kernelci.org
Kernel-build-reports mailing list Kernel-build-reports@lists.linaro.org https://lists.linaro.org/mailman/listinfo/kernel-build-reports