Re: mainline/master boot: 559 boots: 63 failed, 477 passed with 12 offline, 7 conflicts (v4.14-9357-g2bf16b7a73ca)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 16/11/17 22:21, kernelci.org bot wrote:
mainline/master boot: 559 boots: 63 failed, 477 passed with 12 offline, 7 conflicts (v4.14-9357-g2bf16b7a73ca)

Full Boot Summary: https://kernelci.org/boot/all/job/mainline/branch/master/kernel/v4.14-9357-g2bf16b7a73ca/
Full Build Summary: https://kernelci.org/build/mainline/branch/master/kernel/v4.14-9357-g2bf16b7a73ca/

Tree: mainline
Branch: master
Git Describe: v4.14-9357-g2bf16b7a73ca
Git Commit: 2bf16b7a73caf3435f782e4170cfe563675e10f9
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Tested: 102 unique boards, 24 SoC families, 36 builds out of 211

Boot Regressions Detected:

arm:
[...]
    multi_v7_defconfig:
[...]
        tegra124-nyan-big:
            lab-collabora: failing since 1 day (last pass: v4.14-3308-g670ffccb2f91 - first fail: v4.14-3453-ge37e0ee01900)

It seems like the automatic bisection job on staging.kernelci.org
found what might have caused this failure.  It's still an
experimental tool but hopefully it will eventually be useful and
save time when looking for the root cause of boot failures...

Here's what it found:

  commit 7313cfa4f6e30384fa04083698d1e865cf812a6a
  Author: Ben Skeggs <bskeggs@xxxxxxxxxx>
  Date:   Wed Nov 1 03:56:19 2017 +1000

      drm/nouveau/bar: move bar1 initialisation into its own function
BAR2 being done for practical reasons, this is just for consistency. Flushes have been added after the write to bind the instance block,
      as later commits will reveal the need for them.
Signed-off-by: Ben Skeggs <bskeggs@xxxxxxxxxx>


Kernel error:

[    2.402977] nouveau 57000000.gpu: gr: failed to load fuc409c
[    2.456166] Unable to handle kernel NULL pointer dereference at virtual address 00000000


It looks like the same DRM driver issue that was found previously
on linux-next (CC Jon Hunter).  I would be interested to know if
this is actually the commit that introduced the problem, hoping
it can help getting it fixed but also to collect results from the
new bisection tool.  It would be great if you could please let me
know if you find out, and apologies if it isn't.


The full bisection job log:

  https://people.collabora.com/~gtucker/kernelci/bisections/20171117-tegra124-nyan-big-mainline-1513.txt

All the LAVA jobs for this bisection, for the full kernel logs:

  https://lava.collabora.co.uk/scheduler/alljobs?length=25&search=lava-bisect-v2-b-1513#table

The boot results can also be found here by searching for "lava-bisect-v2-b-1513":

  https://staging.kernelci.org/boot/


Hope this helps!

Guillaume

---
For more info write to <info@xxxxxxxxxxxx>



_______________________________________________
Kernel-build-reports mailing list
Kernel-build-reports@xxxxxxxxxxxxxxxx
https://lists.linaro.org/mailman/listinfo/kernel-build-reports


--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux