Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support

[Javier Martinez Canillas]

+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.

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/