next boot: 412 boots: 16 failed, 385 passed with 2 offline, 2 untried/unknown, 7 conflicts (next-20150727)
Full Boot Summary: http://kernelci.org/boot/all/job/next/kernel/next-20150727/ Full Build Summary: http://kernelci.org/build/next/kernel/next-20150727/
Tree: next Branch: local/master Git Describe: next-20150727 Git Commit: 83a5f7f22cae24ea602152424bc9026fdc689ae9 Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Tested: 97 unique boards, 22 SoC families, 27 builds out of 132
Boot Failures Detected: http://kernelci.org/boot/?next-20150727&fail
arm64:
defconfig+CONFIG_OF_UNITTEST=y: hi6220-hikey: 1 failed lab
arm:
tegra_defconfig: tegra30-beaver: 1 failed lab
imx_v6_v7_defconfig: imx6dl-wandboard,wand-dual: 1 failed lab imx6dl-wandboard,wand-solo: 1 failed lab imx6q-cm-fx6: 2 failed labs imx6q-cm-fx6_rootfs:nfs: 1 failed lab imx6q-wandboard: 2 failed labs imx6q-wandboard_rootfs:nfs: 1 failed lab
exynos_defconfig: exynos5422-odroidxu3: 2 failed labs exynos5422-odroidxu3_rootfs:nfs: 1 failed lab exynos5800-peach-pi: 2 failed labs exynos5800-peach-pi_rootfs:mmc: 1 failed lab
Offline Platforms:
arm:
multi_v7_defconfig: am335x-boneblack_rootfs:nfs: 1 offline lab
imx_v6_v7_defconfig: imx6q-cm-fx6_rootfs:nfs: 1 offline lab
Conflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Please review.)
arm64:
defconfig: apq8016-sbc: lab-khilman: PASS lab-tbaker: FAIL
arm:
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y: exynos5422-odroidxu3: lab-khilman: PASS lab-tbaker: FAIL exynos5800-peach-pi: lab-khilman: PASS lab-collabora: FAIL
multi_v7_defconfig: exynos5422-odroidxu3: lab-khilman: PASS lab-tbaker: FAIL exynos5800-peach-pi: lab-khilman: PASS lab-collabora: FAIL
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: exynos5422-odroidxu3: lab-khilman: PASS lab-tbaker: FAIL
multi_v7_defconfig+CONFIG_ARM_LPAE=y: exynos5422-odroidxu3: lab-khilman: PASS lab-tbaker: FAIL
--- For more info write to info@kernelci.org
Hi Kevin and Tyler,
On Mon, Jul 27, 2015 at 9:39 AM, kernelci.org bot bot@kernelci.org wrote:
imx_v6_v7_defconfig: imx6dl-wandboard,wand-dual http://kernelci.org/boot/imx6dl-wandboard,wand-dual/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 1 failed lab imx6dl-wandboard,wand-solo http://kernelci.org/boot/imx6dl-wandboard,wand-solo/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 1 failed lab imx6q-cm-fx6 http://kernelci.org/boot/imx6q-cm-fx6/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 2 failed labs imx6q-cm-fx6_rootfs:nfs http://kernelci.org/boot/imx6q-cm-fx6_rootfs:nfs/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 1 failed lab imx6q-wandboard http://kernelci.org/boot/imx6q-wandboard/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 2 failed labs imx6q-wandboard_rootfs:nfs http://kernelci.org/boot/imx6q-wandboard_rootfs:nfs/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 1 failed lab
Do you know which commit broke the mx6 boot on linux-next 20150727?
Thanks,
Fabio Estevam
On 27 July 2015 at 06:21, Fabio Estevam festevam@gmail.com wrote:
Hi Kevin and Tyler,
On Mon, Jul 27, 2015 at 9:39 AM, kernelci.org bot bot@kernelci.org wrote:
imx_v6_v7_defconfig: imx6dl-wandboard,wand-dual http://kernelci.org/boot/imx6dl-wandboard,wand-dual/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 1 failed lab imx6dl-wandboard,wand-solo http://kernelci.org/boot/imx6dl-wandboard,wand-solo/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 1 failed lab imx6q-cm-fx6 http://kernelci.org/boot/imx6q-cm-fx6/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 2 failed labs imx6q-cm-fx6_rootfs:nfs http://kernelci.org/boot/imx6q-cm-fx6_rootfs:nfs/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 1 failed lab imx6q-wandboard http://kernelci.org/boot/imx6q-wandboard/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 2 failed labs imx6q-wandboard_rootfs:nfs http://kernelci.org/boot/imx6q-wandboard_rootfs:nfs/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 1 failed lab
Do you know which commit broke the mx6 boot on linux-next 20150727?
It's bisecting now:
https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/75/console
On 27 July 2015 at 06:22, Tyler Baker tyler.baker@linaro.org wrote:
On 27 July 2015 at 06:21, Fabio Estevam festevam@gmail.com wrote:
Hi Kevin and Tyler,
On Mon, Jul 27, 2015 at 9:39 AM, kernelci.org bot bot@kernelci.org wrote:
imx_v6_v7_defconfig: imx6dl-wandboard,wand-dual http://kernelci.org/boot/imx6dl-wandboard,wand-dual/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 1 failed lab imx6dl-wandboard,wand-solo http://kernelci.org/boot/imx6dl-wandboard,wand-solo/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 1 failed lab imx6q-cm-fx6 http://kernelci.org/boot/imx6q-cm-fx6/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 2 failed labs imx6q-cm-fx6_rootfs:nfs http://kernelci.org/boot/imx6q-cm-fx6_rootfs:nfs/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 1 failed lab imx6q-wandboard http://kernelci.org/boot/imx6q-wandboard/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 2 failed labs imx6q-wandboard_rootfs:nfs http://kernelci.org/boot/imx6q-wandboard_rootfs:nfs/job/next/kernel/next-20150727/defconfig/imx_v6_v7_defconfig/: 1 failed lab
Do you know which commit broke the mx6 boot on linux-next 20150727?
It's bisecting now:
https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/75/console
It found "net: fec: Ensure clocks are enabled while using mdio bus" (v5) because I bisected between v4.1 and 83a5f7f22ca. I am re-running the bisection between c9805b9986ed ("Revert "net: fec: Ensure clocks are enabled while using mdio bus") and 83a5f7f22ca.
On Mon, Jul 27, 2015 at 11:40 AM, Tyler Baker tyler.baker@linaro.org wrote:
It found "net: fec: Ensure clocks are enabled while using mdio bus" (v5) because I bisected between v4.1 and 83a5f7f22ca. I am re-running the bisection between c9805b9986ed ("Revert "net: fec: Ensure clocks are enabled while using mdio bus") and 83a5f7f22ca.
It seems that the second bisect did not work either. It points to: # first bad commit: [75406b3b17ee5a107b361b4065ad83fe42fff5a8] tty: Convert use of __constant_htons to htons
On 27 July 2015 at 09:26, Fabio Estevam festevam@gmail.com wrote:
On Mon, Jul 27, 2015 at 11:40 AM, Tyler Baker tyler.baker@linaro.org wrote:
It found "net: fec: Ensure clocks are enabled while using mdio bus" (v5) because I bisected between v4.1 and 83a5f7f22ca. I am re-running the bisection between c9805b9986ed ("Revert "net: fec: Ensure clocks are enabled while using mdio bus") and 83a5f7f22ca.
It seems that the second bisect did not work either. It points to: # first bad commit: [75406b3b17ee5a107b361b4065ad83fe42fff5a8] tty: Convert use of __constant_htons to htons
Yes this does not appear to be the culprit, I tried the revert and the issue still remains. If I checkout [347962eb1559] "Merge remote-tracking branch 'ipmi/for-next' in -next everything works fine, however if I checkout the next merge commit [c3e5e4fa730] "Merge remote-tracking branch 'tty/tty-next'" the imx6 platforms no longer boot, due to the garbling of console messages. I'll attempt another bisection the tty/tty-next tree to see if that offers any more insight.
Hi Tyler,
On Mon, Jul 27, 2015 at 2:21 PM, Tyler Baker tyler.baker@linaro.org wrote:
On 27 July 2015 at 09:26, Fabio Estevam festevam@gmail.com wrote:
On Mon, Jul 27, 2015 at 11:40 AM, Tyler Baker tyler.baker@linaro.org wrote:
It found "net: fec: Ensure clocks are enabled while using mdio bus" (v5) because I bisected between v4.1 and 83a5f7f22ca. I am re-running the bisection between c9805b9986ed ("Revert "net: fec: Ensure clocks are enabled while using mdio bus") and 83a5f7f22ca.
It seems that the second bisect did not work either. It points to: # first bad commit: [75406b3b17ee5a107b361b4065ad83fe42fff5a8] tty: Convert use of __constant_htons to htons
Yes this does not appear to be the culprit, I tried the revert and the issue still remains. If I checkout [347962eb1559] "Merge remote-tracking branch 'ipmi/for-next' in -next everything works fine, however if I checkout the next merge commit [c3e5e4fa730] "Merge remote-tracking branch 'tty/tty-next'" the imx6 platforms no longer boot, due to the garbling of console messages. I'll attempt another bisection the tty/tty-next tree to see if that offers any more insight.
It seems that reverting the following commit fixes the problem:
commit e95044ba4fee93f5ea8a1a24b2d921e148503833 Author: David Jander david@protonic.nl Date: Thu Jul 2 16:29:49 2015 +0200
tty: serial: imx.c: Reset UART before activating interrupts
If the UART has been in use before this driver was loaded, IRQs might be active and get fired as soon as we set the handler, which will crash in the spin_lock_irqsave(&sport->port.lock, flags) because port.lock is not initialized until the port is added at the end of probe.
Signed-off-by: David Jander david@protonic.nl Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
Thanks,
Fabio Estevam
On 27 July 2015 at 11:06, Fabio Estevam festevam@gmail.com wrote:
Hi Tyler,
On Mon, Jul 27, 2015 at 2:21 PM, Tyler Baker tyler.baker@linaro.org wrote:
On 27 July 2015 at 09:26, Fabio Estevam festevam@gmail.com wrote:
On Mon, Jul 27, 2015 at 11:40 AM, Tyler Baker tyler.baker@linaro.org wrote:
It found "net: fec: Ensure clocks are enabled while using mdio bus" (v5) because I bisected between v4.1 and 83a5f7f22ca. I am re-running the bisection between c9805b9986ed ("Revert "net: fec: Ensure clocks are enabled while using mdio bus") and 83a5f7f22ca.
It seems that the second bisect did not work either. It points to: # first bad commit: [75406b3b17ee5a107b361b4065ad83fe42fff5a8] tty: Convert use of __constant_htons to htons
Yes this does not appear to be the culprit, I tried the revert and the issue still remains. If I checkout [347962eb1559] "Merge remote-tracking branch 'ipmi/for-next' in -next everything works fine, however if I checkout the next merge commit [c3e5e4fa730] "Merge remote-tracking branch 'tty/tty-next'" the imx6 platforms no longer boot, due to the garbling of console messages. I'll attempt another bisection the tty/tty-next tree to see if that offers any more insight.
It seems that reverting the following commit fixes the problem:
commit e95044ba4fee93f5ea8a1a24b2d921e148503833 Author: David Jander david@protonic.nl Date: Thu Jul 2 16:29:49 2015 +0200
tty: serial: imx.c: Reset UART before activating interrupts If the UART has been in use before this driver was loaded, IRQs might
be active and get fired as soon as we set the handler, which will crash in the spin_lock_irqsave(&sport->port.lock, flags) because port.lock is not initialized until the port is added at the end of probe.
Signed-off-by: David Jander <david@protonic.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Good find. I've confirmed locally that reverting this commit gets the wandboard and utilite-pro booting again. Looks like the bisect was running off the rails due to the fact that no commit in the tty-next merge actually booted on the imx6 platforms :)
On Mon, Jul 27, 2015 at 3:17 PM, Tyler Baker tyler.baker@linaro.org wrote:
Good find. I've confirmed locally that reverting this commit gets the wandboard and utilite-pro booting again. Looks like the bisect was running off the rails due to the fact that no commit in the tty-next merge actually booted on the imx6 platforms :)
Thanks for reporting and looking at this. I have just sent a patch with the revert.
Congratulations on the kernelci bot work. It is an awesome tool!
Regards,
Fabio Estevam
On 27 July 2015 at 11:21, Fabio Estevam festevam@gmail.com wrote:
On Mon, Jul 27, 2015 at 3:17 PM, Tyler Baker tyler.baker@linaro.org wrote:
Good find. I've confirmed locally that reverting this commit gets the wandboard and utilite-pro booting again. Looks like the bisect was running off the rails due to the fact that no commit in the tty-next merge actually booted on the imx6 platforms :)
Thanks for reporting and looking at this. I have just sent a patch with the revert.
No problem at all, thanks for sending the revert.
Congratulations on the kernelci bot work. It is an awesome tool!
Thanks, it's always good to hear people are finding the output useful!
Cheers,
kernel-build-reports@lists.linaro.org