exynos boot falures in linux-next (was: next boot: 94 boots: 79 pass, 13 fail, 2 untried (next-20141117))
FYI...
Various new exynos5 boot failures starting next-20141117. Looking in the boot logs, the boot stops during DRM initialization.
Note that the boot failures are only on exynos_defconfig, and not multi_v7_defconfig.
Excerpt from boot report below, or recent exynos boots can also be explored here:
http://status.armcloud.us/boot/?exynos
Kevin
Kevin's boot bot khilman@kernel.org writes:
Full Build report: http://status.armcloud.us/build/next/kernel/next-20141117/ Full Boot report: http://status.armcloud.us/boot/all/job/next/kernel/next-20141117/
Tree/Branch: next Git describe: next-20141117
Failed boot tests
[...]
exynos5422-odroid-xu3: FAIL: arm-exynos_defconfig http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5422-odroid-xu3.html exynos5250-arndale: FAIL: arm-exynos_defconfig http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5250-arndale.html exynos5800-peach-pi: FAIL: arm-exynos_defconfig http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5800-peach-pi.html
On 17.11.2014 16:57, Kevin Hilman wrote:
FYI...
Various new exynos5 boot failures starting next-20141117. Looking in the boot logs, the boot stops during DRM initialization.
Note that the boot failures are only on exynos_defconfig, and not multi_v7_defconfig.
Cc: +Inki Dae, +dri-devel
This came up on Trats2 board (Exynos 4412) since next-20141105: https://lkml.org/lkml/2014/11/6/125
Disabling DRM helps.
Best regards, Krzysztof
Excerpt from boot report below, or recent exynos boots can also be explored here:
http://status.armcloud.us/boot/?exynos
Kevin
Kevin's boot bot khilman@kernel.org writes:
Full Build report: http://status.armcloud.us/build/next/kernel/next-20141117/ Full Boot report: http://status.armcloud.us/boot/all/job/next/kernel/next-20141117/
Tree/Branch: next Git describe: next-20141117
Failed boot tests
[...]
exynos5422-odroid-xu3: FAIL: arm-exynos_defconfig http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5422-odroid-xu3.html exynos5250-arndale: FAIL: arm-exynos_defconfig http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5250-arndale.html exynos5800-peach-pi: FAIL: arm-exynos_defconfig http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5800-peach-pi.html-- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kevin Hilman khilman@kernel.org writes:
FYI...
Various new exynos5 boot failures starting next-20141117. Looking in the boot logs, the boot stops during DRM initialization.
Note that the boot failures are only on exynos_defconfig, and not multi_v7_defconfig.
As might have been expected, reverting the change that enables the DRM/display options in exynos_defconfig fixes the problem.
Kevin
Excerpt from boot report below, or recent exynos boots can also be explored here:
http://status.armcloud.us/boot/?exynos
Kevin
Kevin's boot bot khilman@kernel.org writes:
Full Build report: http://status.armcloud.us/build/next/kernel/next-20141117/ Full Boot report: http://status.armcloud.us/boot/all/job/next/kernel/next-20141117/
Tree/Branch: next Git describe: next-20141117
Failed boot tests
[...]
exynos5422-odroid-xu3: FAIL: arm-exynos_defconfig http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5422-odroid-xu3.html exynos5250-arndale: FAIL: arm-exynos_defconfig http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5250-arndale.html exynos5800-peach-pi: FAIL: arm-exynos_defconfig http://storage.armcloud.us/kernel-ci/next/next-20141117/arm-exynos_defconfig/boot-exynos5800-peach-pi.html
[1] commit 0ef76aea7a344ac520b02822a8080797fa06124c Author: Javier Martinez Canillas javier.martinez@collabora.co.uk Date: Thu Nov 13 11:51:42 2014 +0900
ARM: exynos_defconfig: Enable options for display panel support
Many Exynos devices have a display panel. Most of them just have a simple panel while others have more complex configurations that requires an embedded DisplayPort (eDP) to LVDS bridges.
This patch enables the following features to be built in the kernel image to support both setups:
- Direct Rendering Manager (DRM) - DRM bridge registration and lookup framework - Parade ps8622/ps8625 eDP/LVDS bridge - NXP ptn3460 eDP/LVDS bridge - Exynos Fully Interactive Mobile Display controller (FIMD) - Panel registration and lookup framework - Simple panels - Backlight & LCD device support
Signed-off-by: Javier Martinez Canillas javier.martinez@collabora.co.uk Tested-by: Kevin Hilman khilman@linaro.org Signed-off-by: Kukjin Kim kgene.kim@samsung.com
Hello Kevin,
On 11/17/2014 11:24 PM, Kevin Hilman wrote:
As might have been expected, reverting the change that enables the DRM/display options in exynos_defconfig fixes the problem.
Kevin
I'm sorry for causing a boot failure but when I first posted that patch, the Exynos DRM driver was working correctly (at least on the Exynos boards I've access to) so it seems the regression was introduced while the patch was posted but not yet picked.
I'm not sure what is the correct step in this case but I'm OK with reverting the patch until the Exynos DRM driver bug is fixed.
Best regards, Javier
Hello all,
On 2014년 11월 18일 08:25, Javier Martinez Canillas wrote:
Hello Kevin,
On 11/17/2014 11:24 PM, Kevin Hilman wrote:
As might have been expected, reverting the change that enables the DRM/display options in exynos_defconfig fixes the problem.
Kevin
I'm sorry for causing a boot failure but when I first posted that patch, the Exynos DRM driver was working correctly (at least on the Exynos boards I've access to) so it seems the regression was introduced while the patch was posted but not yet picked.
I'm not sure what is the correct step in this case but I'm OK with reverting the patch until the Exynos DRM driver bug is fixed.
I found out a bug of Exynos DRM, which is infinite loop issue incurred by -EPROBE_DEFER. I thought that we resolved this issue with some fixups but not yet. The problem is because -EPROBE_DEFER is returned in case of adding a component of a crtc device but one of a connector device. I will fix it up soon.
Thanks for report, Inki Dae
Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Javier Martinez Canillas javier.martinez@collabora.co.uk writes:
Hello Kevin,
On 11/17/2014 11:24 PM, Kevin Hilman wrote:
As might have been expected, reverting the change that enables the DRM/display options in exynos_defconfig fixes the problem.
Kevin
I'm sorry for causing a boot failure but when I first posted that patch, the Exynos DRM driver was working correctly (at least on the Exynos boards I've access to)
Yeah, I tested it at the time as well, so I know it was working.
so it seems the regression was introduced while the patch was posted but not yet picked.
I'm not sure what is the correct step in this case but I'm OK with reverting the patch until the Exynos DRM driver bug is fixed.
I didn't have time to dig, but I'd rather someone track down the DRM problem and fix that, since it was known to be working. I'm guessing it's something simple that can be fixed before the merge window opens.
Kevin
On Mon, Nov 17, 2014 at 7:49 PM, Kevin Hilman khilman@kernel.org wrote:
Javier Martinez Canillas javier.martinez@collabora.co.uk writes:
Hello Kevin,
On 11/17/2014 11:24 PM, Kevin Hilman wrote:
As might have been expected, reverting the change that enables the DRM/display options in exynos_defconfig fixes the problem.
Kevin
I'm sorry for causing a boot failure but when I first posted that patch, the Exynos DRM driver was working correctly (at least on the Exynos boards I've access to)
Yeah, I tested it at the time as well, so I know it was working.
so it seems the regression was introduced while the patch was posted but not yet picked.
I'm not sure what is the correct step in this case but I'm OK with reverting the patch until the Exynos DRM driver bug is fixed.
I didn't have time to dig, but I'd rather someone track down the DRM problem and fix that, since it was known to be working. I'm guessing it's something simple that can be fixed before the merge window opens.
OK, so this DRM problem is turning out to be non-trivial, so I think the defconfig patch should be reverted until the DRM issue is sorted out.
Otherwise, we risk having boot failures in linux-next which may be hiding other problems.
Kevin
Hello Kevin,
On 11/19/2014 06:01 PM, Kevin Hilman wrote:
I'm not sure what is the correct step in this case but I'm OK with reverting the patch until the Exynos DRM driver bug is fixed.
I didn't have time to dig, but I'd rather someone track down the DRM problem and fix that, since it was known to be working. I'm guessing it's something simple that can be fixed before the merge window opens.
OK, so this DRM problem is turning out to be non-trivial, so I think the defconfig patch should be reverted until the DRM issue is sorted out.
Otherwise, we risk having boot failures in linux-next which may be hiding other problems.
Kevin
Agreed with the config revert, so many issues with Exynos DRM in linux-next :(
Best regards, Javier
Javier Martinez Canillas wrote:
+ Olof,
Hello Kevin,
Hi,
On 11/19/2014 06:01 PM, Kevin Hilman wrote:
I'm not sure what is the correct step in this case but I'm OK with reverting the patch until the Exynos DRM driver bug is fixed.
I didn't have time to dig, but I'd rather someone track down the DRM problem and fix that, since it was known to be working. I'm guessing it's something simple that can be fixed before the merge window opens.
OK, so this DRM problem is turning out to be non-trivial, so I think the defconfig patch should be reverted until the DRM issue is sorted out.
Otherwise, we risk having boot failures in linux-next which may be hiding other problems.
Kevin
Agreed with the config revert, so many issues with Exynos DRM in
linux-next :(
Yeah, it could be a best solution at this moment. Let me revert the commit 0ef76aea7a34 ("ARM: exynos_defconfig: Enable options for display panel support") from -next in samsung tree.
Thanks, Kukjin
Hello Kukjin,
On 11/20/2014 02:55 AM, Kukjin Kim wrote:
Yeah, it could be a best solution at this moment. Let me revert the commit 0ef76aea7a34 ("ARM: exynos_defconfig: Enable options for display panel support") from -next in samsung tree.
Maybe now that all the issues with the Exynos DRM driver that were causing boot failures were found and fixed, we can enable these config options again?
After all, the fact that these symbols got enabled is what made the issues to be detected in the first place so is useful to find regressions earlier.
Best regards, Javier
kernel-build-reports@lists.linaro.org
-
Inki Dae -
Javier Martinez Canillas -
Kevin Hilman -
Kevin Hilman -
Krzysztof Kozłowski -
Kukjin Kim