On 4 October 2017 at 16:41, Milosz Wasilewski milosz.wasilewski@linaro.org wrote:
On 3 October 2017 at 21:22, Tom Gall tom.gall@linaro.org wrote:
Soooo that juno boot result is bogus..
On Oct 3, 2017, at 3:11 PM, Linaro QA (beta) qa-reports@linaro.org wrote:
Summary
kernel: 4.4.90-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 255b4a073a820d2f46a1ce1740f1a9be3de9661a git describe: v4.4.89-42-g255b4a073a82 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.89-42-g...
No regressions (compared to build v4.4.89-30-gb547584d016b)
Boards, architectures and test suites:
juno-r2- arm64
- boot
This test has never passed. So sure compared to the ‘last build’ it isn’t a regression. OTOH it *NEVER* has passed.
On the boot failure itself - it was the problem with our build. Fathi already changed the dtb we use on 4.4 kernels and that fixes the problem. I checked locally and I think the LAVA jobs with the change are in the queue.
To be a bit more verbose, it wasn't a problem with the build. The way we deploy kernel/dtb on Juno is by using a recovery image. The recovery tries to use juno-r2.dtb on Juno R2 boards but this dtb doesn't exist in 4.4 kernels. We should use juno-r1.dtb on this board with 4.4 kernels. I've just done a workaround in the recovery image by copying the dtb to juno-r2.dtb which is picked up by the deployment.
milosz
dell-poweredge-r200 - x86_64
- boot
- kselftest
- libhugetlbfs
- ltp-syscalls-tests
Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
-- Linaro QA (beta) https://qa-reports.linaro.org _______________________________________________ Lts-dev mailing list Lts-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lts-dev
Lts-dev mailing list Lts-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lts-dev