Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
Hello Inki, On 03/10/2015 03:50 AM, Inki Dae wrote: > On 2015년 03월 07일 00:07, Javier Martinez Canillas wrote: 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. >> >> I know that I may sound like a broken record but could you please make >> sure that your tree is included in linux-next? > > Got it. I got several requests before. I have created a new branch - > exynos-drm/for-next - based on top of drm-next, which would have same > patch set as existing exynos-drm-next. > > I will request Stephen Rothwell to merge remote-tracking branch, > 'exynos-drm/for-next'. > Great new, thanks a lot. > Thanks, > Inki Dae > Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
On 2015년 03월 07일 00:07, Javier Martinez Canillas wrote: > Hello Inki, > > On 03/06/2015 02:32 PM, Inki Dae wrote: >>> >>> 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, I tested v4.0-rc2 + the patch to disable IOMMU + the patch you > mentioned and the crash does not happen anymore in Peach Pit and Snow. > >>> >>> 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. >>> > > I know that I may sound like a broken record but could you please make > sure that your tree is included in linux-next? Got it. I got several requests before. I have created a new branch - exynos-drm/for-next - based on top of drm-next, which would have same patch set as existing exynos-drm-next. I will request Stephen Rothwell to merge remote-tracking branch, 'exynos-drm/for-next'. Thanks, Inki Dae > > That way the fix could be tested by all the machines that are testing > linux-next daily since right now Exynos will still be broken until you > send a pull request to the DRM maintainer. > > So it would be nice to get the changes as soon as possible into -next > to avoid a recurrent error to mask other possible new issues. > > Best regards, > Javier > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
Hello Inki, On 03/06/2015 02:32 PM, Inki Dae wrote: >> >> 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, I tested v4.0-rc2 + the patch to disable IOMMU + the patch you mentioned and the crash does not happen anymore in Peach Pit and Snow. >> >> 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. >> I know that I may sound like a broken record but could you please make sure that your tree is included in linux-next? That way the fix could be tested by all the machines that are testing linux-next daily since right now Exynos will still be broken until you send a pull request to the DRM maintainer. So it would be nice to get the changes as soon as possible into -next to avoid a recurrent error to mask other possible new issues. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
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 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/schedule
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
Javier Martinez Canillas writes:
> +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 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.
My odroid-xu3 failed, but yours and Tyler's booted. We have different
u-boot versions (mine is mainline), so there may be something bootloader
realted going on with DRM as well:
http://kernelci.org/boot/?exynos_defconfig&exynos5422-odroid
> 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.
This is a concern, but at the same time, exynos has been pretty
consistently broken in -next and in mainline during this cycle (have a
look at this, and set "boot reports per page" to 100":
http://kernelci.org/boot/?exynos_defconfig
This kind of constant breakage causes one form of breakage to mask
others, and we end up getting stuck in situations like this in the -rc
cycle when we should be fixing regressions, not problems that have been
around for months already.
>> 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.
I don't mind so much the brokenness in -next, that's what it's for. The
brokenness in mainline during this part of the -rc cycle is worrisome,
even more so because it's been broken for most of the cycle.
At this point for v4.0-rc, I don't expect there is time to sort out the
proper DRM and have it broadly tested. It's time to fix the regression
in mainline (maybe by disabling some
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
+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 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-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
Hello,
On 2015-03-03 21:36, Kevin Hilman wrote:
Javier Martinez Canillas 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'm starting to think it's the DRM driver that needs to be disabled
until it actually gets some testing, rathre than disabling IOMMU.
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.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
Javier Martinez Canillas 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'm starting to think it's the DRM driver that needs to be disabled
until it actually gets some testing, rathre than disabling IOMMU.
Kevin
[1] http://kernelci.org/boot/?next-20150303&fail
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
Hello Kukjin,
On 03/02/2015 08:43 PM, Kukjin Kim wrote:
> On 02/27/15 15:20, Javier Martinez Canillas wrote:
>> Hello Kukjin,
>>
> Hi,
>
>> On 02/17/2015 12:38 PM, Javier Martinez Canillas wrote:
>>
>> Can you please pick this patch? linux-next is still broken for many Exynos
>> boards after commit 8dcc14f82f06 ("drm/exynos: IOMMU support should not be
>> selectable by user") so we need to disable IOMMU support on Exynos to make
>> them boot again.
>>
>> Here are boot logs of some boards that are affected by this issue:
>>
>> http://storage.kernelci.org/samsung/v4.0-rc1-44-g6a05e2a77140/arm-exynos_defconfig/lab-tbaker/boot-exynos5250-arndale.html
>> http://storage.kernelci.org/samsung/v4.0-rc1-28-g55a4c031ed15/arm-exynos_defconfig/lab-collabora/boot-exynos5800-peach-pi.html
>> http://storage.kernelci.org/samsung/v4.0-rc1-28-g55a4c031ed15/arm-exynos_defconfig/lab-collabora/boot-exynos5250-snow.html
>>
> Thanks, applied.
>
Thanks a lot, please keep in mind that this patch is 4.0 rc material since
the offending commit landed in 4.0-rc1 so Exynos DRM driver breaks the boot.
>> Also there are other exynos_defconfig patches that have been in the list:
>>
>> * [PATCH 1/1] ARM: exynos_defconfig: Enable HDMI support
>> https://lkml.org/lkml/2015/2/6/531
>>
>> * [PATCH] ARM: exynos_defconfig: Enable Marvell WiFi-Ex support
>> https://lkml.org/lkml/2015/2/15/59
>>
> Will have a look soon ;)
>
Great, thanks.
> - Kukjin
>
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
On 02/27/15 15:20, Javier Martinez Canillas wrote:
> Hello Kukjin,
>
Hi,
> On 02/17/2015 12:38 PM, Javier Martinez Canillas wrote:
>> 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.
>>
>> [0]:
>> [1.242183] [ cut here ]
>> [1.246191] kernel BUG at drivers/iommu/exynos-iommu.c:481!
>> [1.251747] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
>> [1.257561] Modules linked in:
>> [1.260603] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
>> 3.19.0-07478-g796e1c55717e #490
>> [1.268412] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [1.274489] task: ee06c000 ti: ee05a000 task.ti: ee05a000
>> [1.279874] PC is at __exynos_sysmmu_enable+0x184/0x190
>> [1.285080] LR is at exynos_iommu_attach_device+0x44/0xb0
>> [1.290461] pc : []lr : []psr: 6193
>> [1.290461] sp : ee05bcf8 ip : fp : ed84aa40
>> [1.301916] r10: ed84a890 r9 : a113 r8 : 6db3
>> [1.307125] r7 : ed84aa40 r6 : r5 : r4 : ee174e10
>> [1.313635] r3 : 6db3 r2 : ed84aa40 r1 : 6db3 r0 : ee174e10
>> [1.320147] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment
>> kernel
>> [1.327524] Control: 10c5387d Table: 4000406a DAC: 0015
>> [1.333252] Process swapper/0 (pid: 1, stack limit = 0xee05a210)
>> [1.339241] Stack: (0xee05bcf8 to 0xee05c000)
>> [1.343581] bce0:
>> 6db3 ee174e10
>> [1.351741] bd00: ed84a880 ed84aa40 ee174e10 a113 ed84a890
>> c0254a64
>> [1.359900] bd20: 6db3 ee174e10 ed84adc0 0005 0034
>> 0001 c0692c1c
>> [1.368059] bd40: 0097 c02526c8 ee29f050 c0017210 ee29f050 ee174e10
>> edab6810 c0282558
>> [1.376219] bd60: edab6a10 ee1cb000 0005 c0283520 ee29f240 c028f210
>> edab6810 ee2ef280
>> [1.384378] bd80: edb24680 ed84a680 ee1cb000 c02883f8 edab6810 ee1cb000
>> ee1cb000
>> [1.392537] bda0: ed84a680 ee2ef450 c027e968 ee1cb000
>> c0268fd4
>> [1.400696] bdc0: edab6800 c06b0de4 ee1cb000 c026a8bc ee2ef0c0 c028f210
>> 0002 ee2ef460
>> [1.408855] bde0: ee2ef460 0002 ee2ef280 c0288728 c04af5d0 edab6810
>> ee2ef280
>> [1.417014] be00: c06b1348 c0288918 c06b0f00 c06b0f00 edab6810 0001
>> c06b0da0 c027eaf4
>> [1.425173] be20: c070334c edaee190 edab6810 ffed c06b0da0
>> c028da1c
>> [1.42] be40: edab6810 c070334c c028c5f8 edab6810 c06b0da0
>> edab6844
>> [1.441492] be60: eda3c740 c028c7a4 c06b0da0 c028c718 c028af74
>> ee005274 ee3b7b40
>> [1.449652] be80: c06b0da0 ee3b7680 c06b1540 c028bde4 c05b6990 c06b0da0
>> c0703324 c06b0da0
>> [1.457811] bea0: c0703324 c069ab18 c028cdc4
>> c0703324 c027ebd8
>> [1.465970] bec0: c05b6990
>> c00c4574
>> [1.474129] bee0: c069ab18 c027eb1c c069ab18
>> c069ab18 c0008944
>> [1.482288] bf00: 0036 c04770e8 ee049800 c06eace0 ee06c000 6113
>> c069eab0
>> [1.490447] bf20: c069eab0 6113 ef7fcabc ef7fcaae
>> c061c594 c0038640
>> [1.498607] bf40: c05cb1d0 c061bc24 0006 0006 c069ea50 c06724d4
>> 0006 c06724b4
>> [1.506766] bf60: c06c7600 c0647588 c0692c1c 0097 c0647d40
>> 0006 0006
>> [1.514925] bf80: c0647588 c003d2d8 c046921c
>>
>> [1.523084] bfa0: c0469224 c000e680
>>
>> [1.531243] bfc0:
>>
>> [1.539402] bfe0: 0013
>>
>> [1.547567] [] (__exynos_sysmmu_enable) from []
>> (exynos_iommu_attach_device+0x44/0xb0)
>> [1.557199] [] (exynos_iommu_attach_device) from []
>> (iommu_attach_device+0x18/0x24)
>> [1.566576] [] (iommu_attach_device) from []
>> (arm_iommu_attach_device+0x18/0x50)
>> [1.575690] [] (arm_iommu_attach_device) from []
>> (drm_iommu_attach_device+0x50/0xb4)
>> [1.585150] [] (drm_iommu_attach_device) from []
>> (fimd_bind+0x94/0x1b8)
>> [1.593483] [] (fimd_bind) from []
>> (component_bind_all+0xb4/0x214)
>> [1.601380] [] (component_bind_all) from []
>> (exynos_drm_load+0x9c/0x13c)
>> [
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
Hello Kukjin,
On 02/17/2015 12:38 PM, Javier Martinez Canillas wrote:
> 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.
>
> [0]:
> [1.242183] [ cut here ]
> [1.246191] kernel BUG at drivers/iommu/exynos-iommu.c:481!
> [1.251747] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> [1.257561] Modules linked in:
> [1.260603] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> 3.19.0-07478-g796e1c55717e #490
> [1.268412] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [1.274489] task: ee06c000 ti: ee05a000 task.ti: ee05a000
> [1.279874] PC is at __exynos_sysmmu_enable+0x184/0x190
> [1.285080] LR is at exynos_iommu_attach_device+0x44/0xb0
> [1.290461] pc : []lr : []psr: 6193
> [1.290461] sp : ee05bcf8 ip : fp : ed84aa40
> [1.301916] r10: ed84a890 r9 : a113 r8 : 6db3
> [1.307125] r7 : ed84aa40 r6 : r5 : r4 : ee174e10
> [1.313635] r3 : 6db3 r2 : ed84aa40 r1 : 6db3 r0 : ee174e10
> [1.320147] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment
> kernel
> [1.327524] Control: 10c5387d Table: 4000406a DAC: 0015
> [1.333252] Process swapper/0 (pid: 1, stack limit = 0xee05a210)
> [1.339241] Stack: (0xee05bcf8 to 0xee05c000)
> [1.343581] bce0:
> 6db3 ee174e10
> [1.351741] bd00: ed84a880 ed84aa40 ee174e10 a113 ed84a890
> c0254a64
> [1.359900] bd20: 6db3 ee174e10 ed84adc0 0005 0034
> 0001 c0692c1c
> [1.368059] bd40: 0097 c02526c8 ee29f050 c0017210 ee29f050 ee174e10
> edab6810 c0282558
> [1.376219] bd60: edab6a10 ee1cb000 0005 c0283520 ee29f240 c028f210
> edab6810 ee2ef280
> [1.384378] bd80: edb24680 ed84a680 ee1cb000 c02883f8 edab6810 ee1cb000
> ee1cb000
> [1.392537] bda0: ed84a680 ee2ef450 c027e968 ee1cb000
> c0268fd4
> [1.400696] bdc0: edab6800 c06b0de4 ee1cb000 c026a8bc ee2ef0c0 c028f210
> 0002 ee2ef460
> [1.408855] bde0: ee2ef460 0002 ee2ef280 c0288728 c04af5d0 edab6810
> ee2ef280
> [1.417014] be00: c06b1348 c0288918 c06b0f00 c06b0f00 edab6810 0001
> c06b0da0 c027eaf4
> [1.425173] be20: c070334c edaee190 edab6810 ffed c06b0da0
> c028da1c
> [1.42] be40: edab6810 c070334c c028c5f8 edab6810 c06b0da0
> edab6844
> [1.441492] be60: eda3c740 c028c7a4 c06b0da0 c028c718 c028af74
> ee005274 ee3b7b40
> [1.449652] be80: c06b0da0 ee3b7680 c06b1540 c028bde4 c05b6990 c06b0da0
> c0703324 c06b0da0
> [1.457811] bea0: c0703324 c069ab18 c028cdc4
> c0703324 c027ebd8
> [1.465970] bec0: c05b6990
> c00c4574
> [1.474129] bee0: c069ab18 c027eb1c c069ab18
> c069ab18 c0008944
> [1.482288] bf00: 0036 c04770e8 ee049800 c06eace0 ee06c000 6113
> c069eab0
> [1.490447] bf20: c069eab0 6113 ef7fcabc ef7fcaae
> c061c594 c0038640
> [1.498607] bf40: c05cb1d0 c061bc24 0006 0006 c069ea50 c06724d4
> 0006 c06724b4
> [1.506766] bf60: c06c7600 c0647588 c0692c1c 0097 c0647d40
> 0006 0006
> [1.514925] bf80: c0647588 c003d2d8 c046921c
>
> [1.523084] bfa0: c0469224 c000e680
>
> [1.531243] bfc0:
>
> [1.539402] bfe0: 0013
>
> [1.547567] [] (__exynos_sysmmu_enable) from []
> (exynos_iommu_attach_device+0x44/0xb0)
> [1.557199] [] (exynos_iommu_attach_device) from []
> (iommu_attach_device+0x18/0x24)
> [1.566576] [] (iommu_attach_device) from []
> (arm_iommu_attach_device+0x18/0x50)
> [1.575690] [] (arm_iommu_attach_device) from []
> (drm_iommu_attach_device+0x50/0xb4)
> [1.585150] [] (drm_iommu_attach_device) from []
> (fimd_bind+0x94/0x1b8)
> [1.593483] [] (fimd_bind) from []
> (component_bind_all+0xb4/0x214)
> [1.601380] [] (component_bind_all) from []
> (exynos_drm_load+0x9c/0x13c)
> [1.609802] [] (exynos_drm_load) from []
> (drm_dev_register+0xa0/0xf4)
> [1.617960] [] (drm_dev_register) from []
> (drm_platform_init+0x44/0xcc)
> [
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
On wto, 2015-02-17 at 13:56 +0100, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> On 02/17/2015 01:20 PM, Krzysztof Kozlowski wrote:
> > On wto, 2015-02-17 at 12:38 +0100, Javier Martinez Canillas wrote:
> >> 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.
> >
> > On which board you got this error?
> >
>
> Sorry, I should had mention it in the commit message. I get that error
> with at least Exynos5800 Peach Pi, Exynos5420 Peach Pit and Exynos5250
> Snow Chromebooks with today's next (next-20150217).
>
> The problem is that the Exynos IOMMU driver does not set a struct
> exynos_iommu_owner in dev.archdata.iommu but __exynos_sysmmu_enable()
> has a BUG_ON(!has_sysmmu(dev)).
>
> Marek's series [1] solves this issue by filling sysmmu devices from DT
> but causes boot failures on the Exynos Chromebooks because the display
> is left enabled by the bootloader [2].
>
> So I think that this option should be disabled until is known to not
> cause issues on any platform.
Sure, I am completely fine with that change. I just wanted to know the
hardware.
Anyway Marek already acked this I won't duplicate the effort :).
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
Hello Krzysztof,
On 02/17/2015 01:20 PM, Krzysztof Kozlowski wrote:
> On wto, 2015-02-17 at 12:38 +0100, Javier Martinez Canillas wrote:
>> 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.
>
> On which board you got this error?
>
Sorry, I should had mention it in the commit message. I get that error
with at least Exynos5800 Peach Pi, Exynos5420 Peach Pit and Exynos5250
Snow Chromebooks with today's next (next-20150217).
The problem is that the Exynos IOMMU driver does not set a struct
exynos_iommu_owner in dev.archdata.iommu but __exynos_sysmmu_enable()
has a BUG_ON(!has_sysmmu(dev)).
Marek's series [1] solves this issue by filling sysmmu devices from DT
but causes boot failures on the Exynos Chromebooks because the display
is left enabled by the bootloader [2].
So I think that this option should be disabled until is known to not
cause issues on any platform.
> Best regards,
> Krzysztof
>
[1]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/319244.html
[2]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/319293.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
Hello,
On 2015-02-17 12:38, Javier Martinez Canillas wrote:
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.
[0]:
[1.242183] [ cut here ]
[1.246191] kernel BUG at drivers/iommu/exynos-iommu.c:481!
[1.251747] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[1.257561] Modules linked in:
[1.260603] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
3.19.0-07478-g796e1c55717e #490
[1.268412] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[1.274489] task: ee06c000 ti: ee05a000 task.ti: ee05a000
[1.279874] PC is at __exynos_sysmmu_enable+0x184/0x190
[1.285080] LR is at exynos_iommu_attach_device+0x44/0xb0
[1.290461] pc : []lr : []psr: 6193
[1.290461] sp : ee05bcf8 ip : fp : ed84aa40
[1.301916] r10: ed84a890 r9 : a113 r8 : 6db3
[1.307125] r7 : ed84aa40 r6 : r5 : r4 : ee174e10
[1.313635] r3 : 6db3 r2 : ed84aa40 r1 : 6db3 r0 : ee174e10
[1.320147] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment
kernel
[1.327524] Control: 10c5387d Table: 4000406a DAC: 0015
[1.333252] Process swapper/0 (pid: 1, stack limit = 0xee05a210)
[1.339241] Stack: (0xee05bcf8 to 0xee05c000)
[1.343581] bce0:
6db3 ee174e10
[1.351741] bd00: ed84a880 ed84aa40 ee174e10 a113 ed84a890
c0254a64
[1.359900] bd20: 6db3 ee174e10 ed84adc0 0005 0034
0001 c0692c1c
[1.368059] bd40: 0097 c02526c8 ee29f050 c0017210 ee29f050 ee174e10
edab6810 c0282558
[1.376219] bd60: edab6a10 ee1cb000 0005 c0283520 ee29f240 c028f210
edab6810 ee2ef280
[1.384378] bd80: edb24680 ed84a680 ee1cb000 c02883f8 edab6810 ee1cb000
ee1cb000
[1.392537] bda0: ed84a680 ee2ef450 c027e968 ee1cb000
c0268fd4
[1.400696] bdc0: edab6800 c06b0de4 ee1cb000 c026a8bc ee2ef0c0 c028f210
0002 ee2ef460
[1.408855] bde0: ee2ef460 0002 ee2ef280 c0288728 c04af5d0 edab6810
ee2ef280
[1.417014] be00: c06b1348 c0288918 c06b0f00 c06b0f00 edab6810 0001
c06b0da0 c027eaf4
[1.425173] be20: c070334c edaee190 edab6810 ffed c06b0da0
c028da1c
[1.42] be40: edab6810 c070334c c028c5f8 edab6810 c06b0da0
edab6844
[1.441492] be60: eda3c740 c028c7a4 c06b0da0 c028c718 c028af74
ee005274 ee3b7b40
[1.449652] be80: c06b0da0 ee3b7680 c06b1540 c028bde4 c05b6990 c06b0da0
c0703324 c06b0da0
[1.457811] bea0: c0703324 c069ab18 c028cdc4
c0703324 c027ebd8
[1.465970] bec0: c05b6990
c00c4574
[1.474129] bee0: c069ab18 c027eb1c c069ab18
c069ab18 c0008944
[1.482288] bf00: 0036 c04770e8 ee049800 c06eace0 ee06c000 6113
c069eab0
[1.490447] bf20: c069eab0 6113 ef7fcabc ef7fcaae
c061c594 c0038640
[1.498607] bf40: c05cb1d0 c061bc24 0006 0006 c069ea50 c06724d4
0006 c06724b4
[1.506766] bf60: c06c7600 c0647588 c0692c1c 0097 c0647d40
0006 0006
[1.514925] bf80: c0647588 c003d2d8 c046921c
[1.523084] bfa0: c0469224 c000e680
[1.531243] bfc0:
[1.539402] bfe0: 0013
[1.547567] [] (__exynos_sysmmu_enable) from []
(exynos_iommu_attach_device+0x44/0xb0)
[1.557199] [] (exynos_iommu_attach_device) from []
(iommu_attach_device+0x18/0x24)
[1.566576] [] (iommu_attach_device) from []
(arm_iommu_attach_device+0x18/0x50)
[1.575690] [] (arm_iommu_attach_device) from []
(drm_iommu_attach_device+0x50/0xb4)
[1.585150] [] (drm_iommu_attach_device) from []
(fimd_bind+0x94/0x1b8)
[1.593483] [] (fimd_bind) from []
(component_bind_all+0xb4/0x214)
[1.601380] [] (component_bind_all) from []
(exynos_drm_load+0x9c/0x13c)
[1.609802] [] (exynos_drm_load) from []
(drm_dev_register+0xa0/0xf4)
[1.617960] [] (drm_dev_register) from []
(drm_platform_init+0x44/0xcc)
[1.626293] [] (drm_platform_init) from []
(try_to_bring_up_master.part.3+0xc8/0x104)
[1.635839] [] (try_to_bring_up_master.part.3) from []
(component_master_add_with_match+0xcc/0x114)
[1.646602] [
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
On wto, 2015-02-17 at 12:38 +0100, Javier Martinez Canillas wrote:
> 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.
On which board you got this error?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
