Hi all,
On 2015년 03월 04일 19:24, Javier Martinez Canillas wrote:
> +Gustavo which has been looking at the issues
>
> Hello,
>
> On 03/04/2015 09:50 AM, Marek Szyprowski wrote:
>> Hello,
>>
>> On 2015-03-03 21:36, Kevin Hilman wrote:
>>> Javier Martinez Canillas <javier.martinez@xxxxxxxxxxxxxxx> writes:
>>>
>>>> Enabling Exynos DRM IOMMU support for Exynos is currently broken and
>>>> causes a BUG on exynos-iommu driver. This was not an issue since the
>>>> options was disabled in exynos_defconfig but after commit 8dcc14f82f06
>>>> ("drm/exynos: IOMMU support should not be selectable by user"), it is
>>>> selected if EXYNOS_IOMMU is enabled which is in exynos_defconfig.
>>>>
>>>> So a kernel built using exynos_defconfig after the mentioned commit
>>>> fails to boot [0]. Disable IOMMU support in Exynos defconfig until
>>>> things get sorted out.
>>> So some other exynos boards started failing in next-20150303[1], and
>>> appear are DRM failures.
>>>
>>> Interestingly, (re)enabling CONFIG_EXYNOS_IOMMU for these cause things to
>>> work again. Even more intersting, with IOMMU enabled, peach-pi is
>>>
>
> I built both 4.0-rc2 and linux-next (tag next-20150303) with and without
> CONFIG_EXYNOS_IOMMU and boot tested on Snow, Peach Pit and Pi.
>
> We still don't have a Peach Pit hooked in LAVA so I tested it locally
> and pasted the boot logs.
>
> 4.0-rc2 (which has CONFIG_EXYNOS_IOMMU enabled)
> -----------------------------------------------
>
> * Snow: NULL pointer dereference at fimd_wait_for_vblank [0]
>
> * Peach Pi: kernel BUG at drivers/iommu/exynos-iommu.c:481 [1]
>
> * Peach Pit: NULL pointer dereference at fimd_wait_for_vblank [2]
>
> 4.0-rc2 + CONFIG_EXYNOS_IOMMU disabled
> --------------------------------------
>
> * Snow: NULL pointer dereference at exynos_plane_destroy [3]
>
> * Peach Pi: no error, kernel booted successfully [4]
>
> * Peach Pit: NULL pointer dereference at exynos_plane_destroy [5]
>
> next-20150303 (which has CONFIG_EXYNOS_IOMMU disabled)
> -----------------------------------------------------
>
> * Snow: no error, kernel booted successfully [6]
> * Peach Pi: no error, kernel booted successfully [7]
> * Peach Pit: no error, kernel booted successfully [8]
>
> next-20150303 + CONFIG_EXYNOS_IOMMU (re)enabled
> -----------------------------------------------
>
> Snow: no error, kernel booted successfully [9]
> Peach Pi: no error, kernel booted successfully [10]
> Peach Pit: no error, kernel booted successfully [11]
>
> Is interesting that the only Exynos5 machines that failed to boot in
> next-20150303 were exynos5250-arndale and exynos5422-odroidxu3 [12].
>
> Also, only the exynos5250-arndale failed to boot with next-20150304 [13]
> while exynos5422-odroidxu3 booted successfully and there were no changes
> for the exynos drm driver between next-20150303 and next-20150304.
>
> Another interesting data point is that the error in next-20150303 for
> these 2 boards was the NULL pointer dereference in exynos_plane_destroy
> that I got with 4.0-rc2 (when IOMMU is disabled) in Snow and Peach Pit.
I think the NULL pointer dereference issue may be fixed with below patch
I merged to exynos-drm-fixes just a while ago,
https://lkml.org/lkml/2015/2/17/434
Could you test it with this patch again?
Thanks,
Inki Dae
>
> So it appears the error is not consistent and may be a race condition.
>
>>> I'm starting to think it's the DRM driver that needs to be disabled
>>> until it actually gets some testing, rathre than disabling IOMMU.
>>
>
> It's true that there are a lot of issues with the Exynos DRM driver
> but OTOH those are exposed because the config is enabled by default.
>
> My fear is that if we disable the driver, it could silently break
> and be noticed much later when a user enables the option.
>
>> Well, this only shows that broken patch has been merged to exynos-drm-next
>> kernel tree. I think that we should keep Exynos DRM enabled and give Exynos
>> DRM developers a chance to fix their stuff and then test their stuff.
>>
>
> Agree, hopefully all these issues are sorted out during the -rc cycle but
> if not then I think we would have to disable the driver as Kevin suggests.
>
> Another thing that may be useful to detect these issues early is to have
> exynos-drm-next be pulled by linux-next since otherwise the integration
> is not tested until the changes are picked by the DRM maintainer.
>
>> Best regards
>>
>
> Best regards,
> Javier
>
> [0]: https://lava.collabora.co.uk/scheduler/job/8559/log_file
> [1]: https://lava.collabora.co.uk/scheduler/job/8558/log_file
> [2]: http://hastebin.com/gupoworepa.xml
> [3]: https://lava.collabora.co.uk/scheduler/job/8560/log_file
> [4]: https://lava.collabora.co.uk/scheduler/job/8566/log_file
> [5]: http://hastebin.com/ziyiruretu.xml
> [6]: https://lava.collabora.co.uk/scheduler/job/8570/log_file
> [7]: https://lava.collabora.co.uk/scheduler/job/8571/log_file
> [8]: http://hastebin.com/felopehimi.vhdl
> [9]: https://lava.collabora.co.uk/scheduler/job/8572/log_file
> [10]: https://lava.collabora.co.uk/scheduler/job/8573/log_file
> [11]: http://hastebin.com/kazupucufu.vhdl
> [12]: http://kernelci.org/boot/?next-20150303&fail
> [13]: http://kernelci.org/boot/?next-20150304&fail
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
