exynos boot falures in linux-next

exynos boot falures in linux-next

[Krzysztof Kozłowski]

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 at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

exynos boot falures in linux-next

[Kevin Hilman]

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>

exynos boot falures in linux-next

[Javier Martinez Canillas]

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

exynos boot falures in linux-next

[Inki Dae]

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 at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

exynos boot falures in linux-next

[Kevin Hilman]

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

exynos boot falures in linux-next

[Kevin Hilman]

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

exynos boot falures in linux-next

[Javier Martinez Canillas]

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

exynos boot falures in linux-next

[Kukjin Kim]

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

exynos boot falures in linux-next

[Javier Martinez Canillas]

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

mirabox boot fails in linux-next (was: next boot: 94 boots: 79 pass, 13 fail, 2 untried (next-20141117))

[Thomas Petazzoni]

Dear Kevin Hilman,

On Mon, 17 Nov 2014 08:09:56 -0800, Kevin Hilman wrote:
> FYI...
> 
> armada-370-mirabox started failing boot tests in linux-next as of
> next-20141117.  Excerpt of boot report below, or you can see all the recent
> boots of mirabox here:
> 
>    http://status.armcloud.us/boot/?mirabox
> 
> I bisected it down to a PCI commit[2], but it didn't revert cleanly on
> top of next/master so didn't fully verify it is the root cause.  I'll
> let one of you MVEBU maintainers take it the next step.

Thanks a lot for the report, very useful. I haven't yet looked at the
PCI commit itself, but reading the commit log indicates that it plays
with sizing the BARs, and we're doing some fairly funky stuff with this
in pci-mvebu, so I'm not entirely surprised such a commit can break
stuff. I'll have a look tomorrow.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com