| Message ID | 1424173109-30347-1-git-send-email-javier.martinez@collabora.co.uk (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 : [<c0254a14>] lr : [<c0254a64>] psr: 60000193 > [ 1.290461] sp : ee05bcf8 ip : 00000000 fp : ed84aa40 > [ 1.301916] r10: ed84a890 r9 : a0000113 r8 : 6db30000 > [ 1.307125] r7 : ed84aa40 r6 : 00000000 r5 : 00000000 r4 : ee174e10 > [ 1.313635] r3 : 6db30000 r2 : ed84aa40 r1 : 6db30000 r0 : ee174e10 > [ 1.320147] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel > [ 1.327524] Control: 10c5387d Table: 4000406a DAC: 00000015 > [ 1.333252] Process swapper/0 (pid: 1, stack limit = 0xee05a210) > [ 1.339241] Stack: (0xee05bcf8 to 0xee05c000) > [ 1.343581] bce0: 6db30000 ee174e10 > [ 1.351741] bd00: ed84a880 00000000 ed84aa40 ee174e10 a0000113 ed84a890 00000000 c0254a64 > [ 1.359900] bd20: 00000000 6db30000 ee174e10 ed84adc0 00000005 00000034 00000001 c0692c1c > [ 1.368059] bd40: 00000097 c02526c8 ee29f050 c0017210 ee29f050 ee174e10 edab6810 c0282558 > [ 1.376219] bd60: edab6a10 ee1cb000 00000005 c0283520 ee29f240 c028f210 edab6810 ee2ef280 > [ 1.384378] bd80: edb24680 ed84a680 ee1cb000 c02883f8 edab6810 ee1cb000 ee1cb000 00000000 > [ 1.392537] bda0: ed84a680 ee2ef450 00000000 c027e968 ee1cb000 00000000 00000000 c0268fd4 > [ 1.400696] bdc0: edab6800 c06b0de4 ee1cb000 c026a8bc ee2ef0c0 c028f210 00000002 ee2ef460 > [ 1.408855] bde0: ee2ef460 00000002 ee2ef280 c0288728 c04af5d0 edab6810 ee2ef280 00000000 > [ 1.417014] be00: c06b1348 c0288918 c06b0f00 c06b0f00 edab6810 00000001 c06b0da0 c027eaf4 > [ 1.425173] be20: c070334c edaee190 00000000 edab6810 ffffffed c06b0da0 00000000 c028da1c > [ 1.433332] be40: edab6810 c070334c 00000000 c028c5f8 edab6810 c06b0da0 edab6844 00000000 > [ 1.441492] be60: eda3c740 c028c7a4 c06b0da0 00000000 c028c718 c028af74 ee005274 ee3b7b40 > [ 1.449652] be80: c06b0da0 ee3b7680 c06b1540 c028bde4 c05b6990 c06b0da0 c0703324 c06b0da0 > [ 1.457811] bea0: c0703324 00000000 c069ab18 c028cdc4 00000000 00000000 c0703324 c027ebd8 > [ 1.465970] bec0: 00000000 c05b6990 ffffffff 00000000 00000000 00000000 00000000 c00c4574 > [ 1.474129] bee0: 00000000 00000000 c069ab18 c027eb1c 00000000 c069ab18 c069ab18 c0008944 > [ 1.482288] bf00: 00000036 c04770e8 ee049800 c06eace0 ee06c000 60000113 c069eab0 00000000 > [ 1.490447] bf20: 00000000 c069eab0 60000113 00000000 ef7fcabc ef7fcaae c061c594 c0038640 > [ 1.498607] bf40: c05cb1d0 c061bc24 00000006 00000006 c069ea50 c06724d4 00000006 c06724b4 > [ 1.506766] bf60: c06c7600 c0647588 c0692c1c 00000097 00000000 c0647d40 00000006 00000006 > [ 1.514925] bf80: c0647588 c003d2d8 00000000 c046921c 00000000 00000000 00000000 00000000 > [ 1.523084] bfa0: 00000000 c0469224 00000000 c000e680 00000000 00000000 00000000 00000000 > [ 1.531243] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 1.539402] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 > [ 1.547567] [<c0254a14>] (__exynos_sysmmu_enable) from [<c0254a64>] (exynos_iommu_attach_device+0x44/0xb0) > [ 1.557199] [<c0254a64>] (exynos_iommu_attach_device) from [<c02526c8>] (iommu_attach_device+0x18/0x24) > [ 1.566576] [<c02526c8>] (iommu_attach_device) from [<c0017210>] (arm_iommu_attach_device+0x18/0x50) > [ 1.575690] [<c0017210>] (arm_iommu_attach_device) from [<c0282558>] (drm_iommu_attach_device+0x50/0xb4) > [ 1.585150] [<c0282558>] (drm_iommu_attach_device) from [<c0283520>] (fimd_bind+0x94/0x1b8) > [ 1.593483] [<c0283520>] (fimd_bind) from [<c02883f8>] (component_bind_all+0xb4/0x214) > [ 1.601380] [<c02883f8>] (component_bind_all) from [<c027e968>] (exynos_drm_load+0x9c/0x13c) > [ 1.609802] [<c027e968>] (exynos_drm_load) from [<c0268fd4>] (drm_dev_register+0xa0/0xf4) > [ 1.617960] [<c0268fd4>] (drm_dev_register) from [<c026a8bc>] (drm_platform_init+0x44/0xcc) > [ 1.626293] [<c026a8bc>] (drm_platform_init) from [<c0288728>] (try_to_bring_up_master.part.3+0xc8/0x104) > [ 1.635839] [<c0288728>] (try_to_bring_up_master.part.3) from [<c0288918>] (component_master_add_with_match+0xcc/0x114) > [ 1.646602] [<c0288918>] (component_master_add_with_match) from [<c027eaf4>] (exynos_drm_platform_probe+0xec/0x114) > [ 1.657019] [<c027eaf4>] (exynos_drm_platform_probe) from [<c028da1c>] (platform_drv_probe+0x48/0x98) > [ 1.666221] [<c028da1c>] (platform_drv_probe) from [<c028c5f8>] (driver_probe_device+0x114/0x234) > [ 1.675075] [<c028c5f8>] (driver_probe_device) from [<c028c7a4>] (__driver_attach+0x8c/0x90) > [ 1.683494] [<c028c7a4>] (__driver_attach) from [<c028af74>] (bus_for_each_dev+0x54/0x88) > [ 1.691653] [<c028af74>] (bus_for_each_dev) from [<c028bde4>] (bus_add_driver+0xd8/0x1cc) > [ 1.699812] [<c028bde4>] (bus_add_driver) from [<c028cdc4>] (driver_register+0x78/0xf4) > [ 1.707797] [<c028cdc4>] (driver_register) from [<c027ebd8>] (exynos_drm_init+0xbc/0x110) > [ 1.715956] [<c027ebd8>] (exynos_drm_init) from [<c0008944>] (do_one_initcall+0x80/0x1d0) > [ 1.724117] [<c0008944>] (do_one_initcall) from [<c0647d40>] (kernel_init_freeable+0x108/0x1d4) > [ 1.732796] [<c0647d40>] (kernel_init_freeable) from [<c0469224>] (kernel_init+0x8/0xe4) > [ 1.740869] [<c0469224>] (kernel_init) from [<c000e680>] (ret_from_fork+0x14/0x34) > [ 1.748419] Code: e3403110 11a02001 01a02003 eaffffe4 (e7f001f2) > [ 1.754502] ---[ end trace f58ad362326928d7 ]--- > > Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Right, it is better to disable it in defconfig to give users system which at least boots correctly. > --- > arch/arm/configs/exynos_defconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig > index 70e5d0bdb4e4..3d22aae39a83 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -176,7 +176,6 @@ CONFIG_PL330_DMA=y > CONFIG_COMMON_CLK_MAX77686=y > CONFIG_COMMON_CLK_MAX77802=y > CONFIG_COMMON_CLK_S2MPS11=y > -CONFIG_EXYNOS_IOMMU=y > CONFIG_EXTCON=y > CONFIG_EXTCON_MAX14577=y > CONFIG_EXTCON_MAX77693=y Best regards
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 : [<c0254a14>] lr : [<c0254a64>] psr: 60000193 > [ 1.290461] sp : ee05bcf8 ip : 00000000 fp : ed84aa40 > [ 1.301916] r10: ed84a890 r9 : a0000113 r8 : 6db30000 > [ 1.307125] r7 : ed84aa40 r6 : 00000000 r5 : 00000000 r4 : ee174e10 > [ 1.313635] r3 : 6db30000 r2 : ed84aa40 r1 : 6db30000 r0 : ee174e10 > [ 1.320147] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel > [ 1.327524] Control: 10c5387d Table: 4000406a DAC: 00000015 > [ 1.333252] Process swapper/0 (pid: 1, stack limit = 0xee05a210) > [ 1.339241] Stack: (0xee05bcf8 to 0xee05c000) > [ 1.343581] bce0: 6db30000 ee174e10 > [ 1.351741] bd00: ed84a880 00000000 ed84aa40 ee174e10 a0000113 ed84a890 00000000 c0254a64 > [ 1.359900] bd20: 00000000 6db30000 ee174e10 ed84adc0 00000005 00000034 00000001 c0692c1c > [ 1.368059] bd40: 00000097 c02526c8 ee29f050 c0017210 ee29f050 ee174e10 edab6810 c0282558 > [ 1.376219] bd60: edab6a10 ee1cb000 00000005 c0283520 ee29f240 c028f210 edab6810 ee2ef280 > [ 1.384378] bd80: edb24680 ed84a680 ee1cb000 c02883f8 edab6810 ee1cb000 ee1cb000 00000000 > [ 1.392537] bda0: ed84a680 ee2ef450 00000000 c027e968 ee1cb000 00000000 00000000 c0268fd4 > [ 1.400696] bdc0: edab6800 c06b0de4 ee1cb000 c026a8bc ee2ef0c0 c028f210 00000002 ee2ef460 > [ 1.408855] bde0: ee2ef460 00000002 ee2ef280 c0288728 c04af5d0 edab6810 ee2ef280 00000000 > [ 1.417014] be00: c06b1348 c0288918 c06b0f00 c06b0f00 edab6810 00000001 c06b0da0 c027eaf4 > [ 1.425173] be20: c070334c edaee190 00000000 edab6810 ffffffed c06b0da0 00000000 c028da1c > [ 1.433332] be40: edab6810 c070334c 00000000 c028c5f8 edab6810 c06b0da0 edab6844 00000000 > [ 1.441492] be60: eda3c740 c028c7a4 c06b0da0 00000000 c028c718 c028af74 ee005274 ee3b7b40 > [ 1.449652] be80: c06b0da0 ee3b7680 c06b1540 c028bde4 c05b6990 c06b0da0 c0703324 c06b0da0 > [ 1.457811] bea0: c0703324 00000000 c069ab18 c028cdc4 00000000 00000000 c0703324 c027ebd8 > [ 1.465970] bec0: 00000000 c05b6990 ffffffff 00000000 00000000 00000000 00000000 c00c4574 > [ 1.474129] bee0: 00000000 00000000 c069ab18 c027eb1c 00000000 c069ab18 c069ab18 c0008944 > [ 1.482288] bf00: 00000036 c04770e8 ee049800 c06eace0 ee06c000 60000113 c069eab0 00000000 > [ 1.490447] bf20: 00000000 c069eab0 60000113 00000000 ef7fcabc ef7fcaae c061c594 c0038640 > [ 1.498607] bf40: c05cb1d0 c061bc24 00000006 00000006 c069ea50 c06724d4 00000006 c06724b4 > [ 1.506766] bf60: c06c7600 c0647588 c0692c1c 00000097 00000000 c0647d40 00000006 00000006 > [ 1.514925] bf80: c0647588 c003d2d8 00000000 c046921c 00000000 00000000 00000000 00000000 > [ 1.523084] bfa0: 00000000 c0469224 00000000 c000e680 00000000 00000000 00000000 00000000 > [ 1.531243] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 1.539402] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 > [ 1.547567] [<c0254a14>] (__exynos_sysmmu_enable) from [<c0254a64>] (exynos_iommu_attach_device+0x44/0xb0) > [ 1.557199] [<c0254a64>] (exynos_iommu_attach_device) from [<c02526c8>] (iommu_attach_device+0x18/0x24) > [ 1.566576] [<c02526c8>] (iommu_attach_device) from [<c0017210>] (arm_iommu_attach_device+0x18/0x50) > [ 1.575690] [<c0017210>] (arm_iommu_attach_device) from [<c0282558>] (drm_iommu_attach_device+0x50/0xb4) > [ 1.585150] [<c0282558>] (drm_iommu_attach_device) from [<c0283520>] (fimd_bind+0x94/0x1b8) > [ 1.593483] [<c0283520>] (fimd_bind) from [<c02883f8>] (component_bind_all+0xb4/0x214) > [ 1.601380] [<c02883f8>] (component_bind_all) from [<c027e968>] (exynos_drm_load+0x9c/0x13c) > [ 1.609802] [<c027e968>] (exynos_drm_load) from [<c0268fd4>] (drm_dev_register+0xa0/0xf4) > [ 1.617960] [<c0268fd4>] (drm_dev_register) from [<c026a8bc>] (drm_platform_init+0x44/0xcc) > [ 1.626293] [<c026a8bc>] (drm_platform_init) from [<c0288728>] (try_to_bring_up_master.part.3+0xc8/0x104) > [ 1.635839] [<c0288728>] (try_to_bring_up_master.part.3) from [<c0288918>] (component_master_add_with_match+0xcc/0x114) > [ 1.646602] [<c0288918>] (component_master_add_with_match) from [<c027eaf4>] (exynos_drm_platform_probe+0xec/0x114) > [ 1.657019] [<c027eaf4>] (exynos_drm_platform_probe) from [<c028da1c>] (platform_drv_probe+0x48/0x98) > [ 1.666221] [<c028da1c>] (platform_drv_probe) from [<c028c5f8>] (driver_probe_device+0x114/0x234) > [ 1.675075] [<c028c5f8>] (driver_probe_device) from [<c028c7a4>] (__driver_attach+0x8c/0x90) > [ 1.683494] [<c028c7a4>] (__driver_attach) from [<c028af74>] (bus_for_each_dev+0x54/0x88) > [ 1.691653] [<c028af74>] (bus_for_each_dev) from [<c028bde4>] (bus_add_driver+0xd8/0x1cc) > [ 1.699812] [<c028bde4>] (bus_add_driver) from [<c028cdc4>] (driver_register+0x78/0xf4) > [ 1.707797] [<c028cdc4>] (driver_register) from [<c027ebd8>] (exynos_drm_init+0xbc/0x110) > [ 1.715956] [<c027ebd8>] (exynos_drm_init) from [<c0008944>] (do_one_initcall+0x80/0x1d0) > [ 1.724117] [<c0008944>] (do_one_initcall) from [<c0647d40>] (kernel_init_freeable+0x108/0x1d4) > [ 1.732796] [<c0647d40>] (kernel_init_freeable) from [<c0469224>] (kernel_init+0x8/0xe4) > [ 1.740869] [<c0469224>] (kernel_init) from [<c000e680>] (ret_from_fork+0x14/0x34) > [ 1.748419] Code: e3403110 11a02001 01a02003 eaffffe4 (e7f001f2) > [ 1.754502] ---[ end trace f58ad362326928d7 ]--- > > Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> 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 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 Thanks a lot and 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
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 : [<c0254a14>] lr : [<c0254a64>] psr: 60000193 >> [ 1.290461] sp : ee05bcf8 ip : 00000000 fp : ed84aa40 >> [ 1.301916] r10: ed84a890 r9 : a0000113 r8 : 6db30000 >> [ 1.307125] r7 : ed84aa40 r6 : 00000000 r5 : 00000000 r4 : ee174e10 >> [ 1.313635] r3 : 6db30000 r2 : ed84aa40 r1 : 6db30000 r0 : ee174e10 >> [ 1.320147] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel >> [ 1.327524] Control: 10c5387d Table: 4000406a DAC: 00000015 >> [ 1.333252] Process swapper/0 (pid: 1, stack limit = 0xee05a210) >> [ 1.339241] Stack: (0xee05bcf8 to 0xee05c000) >> [ 1.343581] bce0: 6db30000 ee174e10 >> [ 1.351741] bd00: ed84a880 00000000 ed84aa40 ee174e10 a0000113 ed84a890 00000000 c0254a64 >> [ 1.359900] bd20: 00000000 6db30000 ee174e10 ed84adc0 00000005 00000034 00000001 c0692c1c >> [ 1.368059] bd40: 00000097 c02526c8 ee29f050 c0017210 ee29f050 ee174e10 edab6810 c0282558 >> [ 1.376219] bd60: edab6a10 ee1cb000 00000005 c0283520 ee29f240 c028f210 edab6810 ee2ef280 >> [ 1.384378] bd80: edb24680 ed84a680 ee1cb000 c02883f8 edab6810 ee1cb000 ee1cb000 00000000 >> [ 1.392537] bda0: ed84a680 ee2ef450 00000000 c027e968 ee1cb000 00000000 00000000 c0268fd4 >> [ 1.400696] bdc0: edab6800 c06b0de4 ee1cb000 c026a8bc ee2ef0c0 c028f210 00000002 ee2ef460 >> [ 1.408855] bde0: ee2ef460 00000002 ee2ef280 c0288728 c04af5d0 edab6810 ee2ef280 00000000 >> [ 1.417014] be00: c06b1348 c0288918 c06b0f00 c06b0f00 edab6810 00000001 c06b0da0 c027eaf4 >> [ 1.425173] be20: c070334c edaee190 00000000 edab6810 ffffffed c06b0da0 00000000 c028da1c >> [ 1.433332] be40: edab6810 c070334c 00000000 c028c5f8 edab6810 c06b0da0 edab6844 00000000 >> [ 1.441492] be60: eda3c740 c028c7a4 c06b0da0 00000000 c028c718 c028af74 ee005274 ee3b7b40 >> [ 1.449652] be80: c06b0da0 ee3b7680 c06b1540 c028bde4 c05b6990 c06b0da0 c0703324 c06b0da0 >> [ 1.457811] bea0: c0703324 00000000 c069ab18 c028cdc4 00000000 00000000 c0703324 c027ebd8 >> [ 1.465970] bec0: 00000000 c05b6990 ffffffff 00000000 00000000 00000000 00000000 c00c4574 >> [ 1.474129] bee0: 00000000 00000000 c069ab18 c027eb1c 00000000 c069ab18 c069ab18 c0008944 >> [ 1.482288] bf00: 00000036 c04770e8 ee049800 c06eace0 ee06c000 60000113 c069eab0 00000000 >> [ 1.490447] bf20: 00000000 c069eab0 60000113 00000000 ef7fcabc ef7fcaae c061c594 c0038640 >> [ 1.498607] bf40: c05cb1d0 c061bc24 00000006 00000006 c069ea50 c06724d4 00000006 c06724b4 >> [ 1.506766] bf60: c06c7600 c0647588 c0692c1c 00000097 00000000 c0647d40 00000006 00000006 >> [ 1.514925] bf80: c0647588 c003d2d8 00000000 c046921c 00000000 00000000 00000000 00000000 >> [ 1.523084] bfa0: 00000000 c0469224 00000000 c000e680 00000000 00000000 00000000 00000000 >> [ 1.531243] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >> [ 1.539402] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 >> [ 1.547567] [<c0254a14>] (__exynos_sysmmu_enable) from [<c0254a64>] (exynos_iommu_attach_device+0x44/0xb0) >> [ 1.557199] [<c0254a64>] (exynos_iommu_attach_device) from [<c02526c8>] (iommu_attach_device+0x18/0x24) >> [ 1.566576] [<c02526c8>] (iommu_attach_device) from [<c0017210>] (arm_iommu_attach_device+0x18/0x50) >> [ 1.575690] [<c0017210>] (arm_iommu_attach_device) from [<c0282558>] (drm_iommu_attach_device+0x50/0xb4) >> [ 1.585150] [<c0282558>] (drm_iommu_attach_device) from [<c0283520>] (fimd_bind+0x94/0x1b8) >> [ 1.593483] [<c0283520>] (fimd_bind) from [<c02883f8>] (component_bind_all+0xb4/0x214) >> [ 1.601380] [<c02883f8>] (component_bind_all) from [<c027e968>] (exynos_drm_load+0x9c/0x13c) >> [ 1.609802] [<c027e968>] (exynos_drm_load) from [<c0268fd4>] (drm_dev_register+0xa0/0xf4) >> [ 1.617960] [<c0268fd4>] (drm_dev_register) from [<c026a8bc>] (drm_platform_init+0x44/0xcc) >> [ 1.626293] [<c026a8bc>] (drm_platform_init) from [<c0288728>] (try_to_bring_up_master.part.3+0xc8/0x104) >> [ 1.635839] [<c0288728>] (try_to_bring_up_master.part.3) from [<c0288918>] (component_master_add_with_match+0xcc/0x114) >> [ 1.646602] [<c0288918>] (component_master_add_with_match) from [<c027eaf4>] (exynos_drm_platform_probe+0xec/0x114) >> [ 1.657019] [<c027eaf4>] (exynos_drm_platform_probe) from [<c028da1c>] (platform_drv_probe+0x48/0x98) >> [ 1.666221] [<c028da1c>] (platform_drv_probe) from [<c028c5f8>] (driver_probe_device+0x114/0x234) >> [ 1.675075] [<c028c5f8>] (driver_probe_device) from [<c028c7a4>] (__driver_attach+0x8c/0x90) >> [ 1.683494] [<c028c7a4>] (__driver_attach) from [<c028af74>] (bus_for_each_dev+0x54/0x88) >> [ 1.691653] [<c028af74>] (bus_for_each_dev) from [<c028bde4>] (bus_add_driver+0xd8/0x1cc) >> [ 1.699812] [<c028bde4>] (bus_add_driver) from [<c028cdc4>] (driver_register+0x78/0xf4) >> [ 1.707797] [<c028cdc4>] (driver_register) from [<c027ebd8>] (exynos_drm_init+0xbc/0x110) >> [ 1.715956] [<c027ebd8>] (exynos_drm_init) from [<c0008944>] (do_one_initcall+0x80/0x1d0) >> [ 1.724117] [<c0008944>] (do_one_initcall) from [<c0647d40>] (kernel_init_freeable+0x108/0x1d4) >> [ 1.732796] [<c0647d40>] (kernel_init_freeable) from [<c0469224>] (kernel_init+0x8/0xe4) >> [ 1.740869] [<c0469224>] (kernel_init) from [<c000e680>] (ret_from_fork+0x14/0x34) >> [ 1.748419] Code: e3403110 11a02001 01a02003 eaffffe4 (e7f001f2) >> [ 1.754502] ---[ end trace f58ad362326928d7 ]--- >> >> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> > > > 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. > 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 ;) - Kukjin -- 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
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Javier Martinez Canillas <javier.martinez@collabora.co.uk> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, On 2015-03-03 21:36, Kevin Hilman wrote: > Javier Martinez Canillas <javier.martinez@collabora.co.uk> 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
+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@collabora.co.uk> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Javier Martinez Canillas <javier.martinez@collabora.co.uk> 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 <javier.martinez@collabora.co.uk> 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 options), and sort out the right fix in -next. > 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. Agreed. Kevin -- 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
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@collabora.co.uk> 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@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 70e5d0bdb4e4..3d22aae39a83 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -176,7 +176,6 @@ CONFIG_PL330_DMA=y CONFIG_COMMON_CLK_MAX77686=y CONFIG_COMMON_CLK_MAX77802=y CONFIG_COMMON_CLK_S2MPS11=y -CONFIG_EXYNOS_IOMMU=y CONFIG_EXTCON=y CONFIG_EXTCON_MAX14577=y CONFIG_EXTCON_MAX77693=y
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 : [<c0254a14>] lr : [<c0254a64>] psr: 60000193 [ 1.290461] sp : ee05bcf8 ip : 00000000 fp : ed84aa40 [ 1.301916] r10: ed84a890 r9 : a0000113 r8 : 6db30000 [ 1.307125] r7 : ed84aa40 r6 : 00000000 r5 : 00000000 r4 : ee174e10 [ 1.313635] r3 : 6db30000 r2 : ed84aa40 r1 : 6db30000 r0 : ee174e10 [ 1.320147] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 1.327524] Control: 10c5387d Table: 4000406a DAC: 00000015 [ 1.333252] Process swapper/0 (pid: 1, stack limit = 0xee05a210) [ 1.339241] Stack: (0xee05bcf8 to 0xee05c000) [ 1.343581] bce0: 6db30000 ee174e10 [ 1.351741] bd00: ed84a880 00000000 ed84aa40 ee174e10 a0000113 ed84a890 00000000 c0254a64 [ 1.359900] bd20: 00000000 6db30000 ee174e10 ed84adc0 00000005 00000034 00000001 c0692c1c [ 1.368059] bd40: 00000097 c02526c8 ee29f050 c0017210 ee29f050 ee174e10 edab6810 c0282558 [ 1.376219] bd60: edab6a10 ee1cb000 00000005 c0283520 ee29f240 c028f210 edab6810 ee2ef280 [ 1.384378] bd80: edb24680 ed84a680 ee1cb000 c02883f8 edab6810 ee1cb000 ee1cb000 00000000 [ 1.392537] bda0: ed84a680 ee2ef450 00000000 c027e968 ee1cb000 00000000 00000000 c0268fd4 [ 1.400696] bdc0: edab6800 c06b0de4 ee1cb000 c026a8bc ee2ef0c0 c028f210 00000002 ee2ef460 [ 1.408855] bde0: ee2ef460 00000002 ee2ef280 c0288728 c04af5d0 edab6810 ee2ef280 00000000 [ 1.417014] be00: c06b1348 c0288918 c06b0f00 c06b0f00 edab6810 00000001 c06b0da0 c027eaf4 [ 1.425173] be20: c070334c edaee190 00000000 edab6810 ffffffed c06b0da0 00000000 c028da1c [ 1.433332] be40: edab6810 c070334c 00000000 c028c5f8 edab6810 c06b0da0 edab6844 00000000 [ 1.441492] be60: eda3c740 c028c7a4 c06b0da0 00000000 c028c718 c028af74 ee005274 ee3b7b40 [ 1.449652] be80: c06b0da0 ee3b7680 c06b1540 c028bde4 c05b6990 c06b0da0 c0703324 c06b0da0 [ 1.457811] bea0: c0703324 00000000 c069ab18 c028cdc4 00000000 00000000 c0703324 c027ebd8 [ 1.465970] bec0: 00000000 c05b6990 ffffffff 00000000 00000000 00000000 00000000 c00c4574 [ 1.474129] bee0: 00000000 00000000 c069ab18 c027eb1c 00000000 c069ab18 c069ab18 c0008944 [ 1.482288] bf00: 00000036 c04770e8 ee049800 c06eace0 ee06c000 60000113 c069eab0 00000000 [ 1.490447] bf20: 00000000 c069eab0 60000113 00000000 ef7fcabc ef7fcaae c061c594 c0038640 [ 1.498607] bf40: c05cb1d0 c061bc24 00000006 00000006 c069ea50 c06724d4 00000006 c06724b4 [ 1.506766] bf60: c06c7600 c0647588 c0692c1c 00000097 00000000 c0647d40 00000006 00000006 [ 1.514925] bf80: c0647588 c003d2d8 00000000 c046921c 00000000 00000000 00000000 00000000 [ 1.523084] bfa0: 00000000 c0469224 00000000 c000e680 00000000 00000000 00000000 00000000 [ 1.531243] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.539402] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 1.547567] [<c0254a14>] (__exynos_sysmmu_enable) from [<c0254a64>] (exynos_iommu_attach_device+0x44/0xb0) [ 1.557199] [<c0254a64>] (exynos_iommu_attach_device) from [<c02526c8>] (iommu_attach_device+0x18/0x24) [ 1.566576] [<c02526c8>] (iommu_attach_device) from [<c0017210>] (arm_iommu_attach_device+0x18/0x50) [ 1.575690] [<c0017210>] (arm_iommu_attach_device) from [<c0282558>] (drm_iommu_attach_device+0x50/0xb4) [ 1.585150] [<c0282558>] (drm_iommu_attach_device) from [<c0283520>] (fimd_bind+0x94/0x1b8) [ 1.593483] [<c0283520>] (fimd_bind) from [<c02883f8>] (component_bind_all+0xb4/0x214) [ 1.601380] [<c02883f8>] (component_bind_all) from [<c027e968>] (exynos_drm_load+0x9c/0x13c) [ 1.609802] [<c027e968>] (exynos_drm_load) from [<c0268fd4>] (drm_dev_register+0xa0/0xf4) [ 1.617960] [<c0268fd4>] (drm_dev_register) from [<c026a8bc>] (drm_platform_init+0x44/0xcc) [ 1.626293] [<c026a8bc>] (drm_platform_init) from [<c0288728>] (try_to_bring_up_master.part.3+0xc8/0x104) [ 1.635839] [<c0288728>] (try_to_bring_up_master.part.3) from [<c0288918>] (component_master_add_with_match+0xcc/0x114) [ 1.646602] [<c0288918>] (component_master_add_with_match) from [<c027eaf4>] (exynos_drm_platform_probe+0xec/0x114) [ 1.657019] [<c027eaf4>] (exynos_drm_platform_probe) from [<c028da1c>] (platform_drv_probe+0x48/0x98) [ 1.666221] [<c028da1c>] (platform_drv_probe) from [<c028c5f8>] (driver_probe_device+0x114/0x234) [ 1.675075] [<c028c5f8>] (driver_probe_device) from [<c028c7a4>] (__driver_attach+0x8c/0x90) [ 1.683494] [<c028c7a4>] (__driver_attach) from [<c028af74>] (bus_for_each_dev+0x54/0x88) [ 1.691653] [<c028af74>] (bus_for_each_dev) from [<c028bde4>] (bus_add_driver+0xd8/0x1cc) [ 1.699812] [<c028bde4>] (bus_add_driver) from [<c028cdc4>] (driver_register+0x78/0xf4) [ 1.707797] [<c028cdc4>] (driver_register) from [<c027ebd8>] (exynos_drm_init+0xbc/0x110) [ 1.715956] [<c027ebd8>] (exynos_drm_init) from [<c0008944>] (do_one_initcall+0x80/0x1d0) [ 1.724117] [<c0008944>] (do_one_initcall) from [<c0647d40>] (kernel_init_freeable+0x108/0x1d4) [ 1.732796] [<c0647d40>] (kernel_init_freeable) from [<c0469224>] (kernel_init+0x8/0xe4) [ 1.740869] [<c0469224>] (kernel_init) from [<c000e680>] (ret_from_fork+0x14/0x34) [ 1.748419] Code: e3403110 11a02001 01a02003 eaffffe4 (e7f001f2) [ 1.754502] ---[ end trace f58ad362326928d7 ]--- Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> --- arch/arm/configs/exynos_defconfig | 1 - 1 file changed, 1 deletion(-)