Help: Samsung Exynos 7870 DECON SYSMMU panic

Kaustabh Chakraborty kauschluss at disroot.org
Wed Jun 25 10:12:25 UTC 2025


On 2025-06-25 08:42, Marek Szyprowski wrote:
> On 25.06.2025 09:39, Kaustabh Chakraborty wrote:
>> On 2025-06-24 17:12, Robin Murphy wrote:
>>> On 2025-06-18 3:02 pm, Kaustabh Chakraborty wrote:
>>>> Since bcb81ac6ae3c (iommu: Get DT/ACPI parsing into the proper probe
>>>> path),
>>>> The Samsung Exynos 7870 DECON device (with patches [1], [2], and
>>>> [3]) seems
>>>> to not work anymore. Upon closer inspection, I observe that there is 
>>>> an
>>>> IOMMU crash.
>>>> 
>>>> [    2.918189] exynos-sysmmu 14860000.sysmmu: 14830000.decon: [READ]
>>>> PAGE FAULT occurred at 0x6715b3e0
>>>> [    2.918199] exynos-sysmmu 14860000.sysmmu: Page table base:
>>>> 0x0000000044a14000
>>>> [    2.918243] exynos-drm exynos-drm: bound 14830000.decon (ops
>>>> decon_component_ops)
>>>> [    2.922868] exynos-sysmmu 14860000.sysmmu:   Lv1 entry: 0x4205001
>>>> [    2.922877] Kernel panic - not syncing: Unrecoverable System MMU
>>>> Fault!
>>>> [    2.922885] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted
>>>> 6.16.0-rc2-exynos7870 #722 PREEMPT
>>>> [    2.995312] Hardware name: Samsung Galaxy J7 Prime (DT)
>>>> [    3.000509] Call trace:
>>>> [    3.002938]  show_stack+0x18/0x24 (C)
>>>> [    3.006582]  dump_stack_lvl+0x60/0x80
>>>> [    3.010224]  dump_stack+0x18/0x24
>>>> [    3.013521]  panic+0x168/0x360
>>>> [    3.016558]  exynos_sysmmu_irq+0x224/0x2ac
>>>> [         ...]
>>>> [    3.108786] ---[ end Kernel panic - not syncing: Unrecoverable
>>>> System MMU Fault! ]---
>>> 
>>> For starters, what if you just remove this panic() from the IOMMU
>>> driver? Frankly it seems a bit excessive anyway...
>> 
>> I've tried that, sysmmu repeatedly keeps issuing interrupts (yes, even
>> after clearing the interrupt bit) indefinitely.
>> 
> Right, this is because decon device is still accessing system memory in
> a loop trying to display the splash screen. That panic is indeed a bit
> excessive, but what else IOMMU driver can do if no page fault handle is
> registered?
> 
> 
>>> 
>>> From the logs below it seems there is apparently unexpected traffic
>>> already going through the IOMMU when it wakes up. Is this the DRM
>>> drivers doing something sketchy, or has the bootloader left the
>>> display running for a splash screen? However in the latter case I
>>> don't obviously see why delaying the IOMMU probe should make much
>>> difference, given that the decon driver should still be waiting for
>>> it either way.
>> 
>> The display is initialized by the bootloader for splash yes, but I 
>> reckon
>> it doesn't use the IOMMU as it's accessible from a framebuffer region.
> 
> Right, bootloader configured decon device to display splash screen, 
> what
> means that decon device is constantly reading splash screen pixel data
> from system memory. There is no such thing as a 'framebuffer region', 
> it
> is just a system memory, which exynos sysmmu protects when enabled. So
> far this issue of splash screen from bootloader has not yet been solved
> in mainline. On other Exynos based supported boards this works only
> because there are also power domain drivers enabled, which are
> instantiated before the display related device and respective sysmmu
> device. That power domain driver shuts down power effectively disabling
> the display before the sysmmu gets probbed.
> 
> Long time ago I've pointed this issue and proposed some simple solution
> like a special initial identity mapping for the memory range used for
> splash screen, but that proposal is no longer applicable for the 
> current
> code.
> 
> As a workaround I would suggest to shutdown display in the decon device
> before starting the kernel (i.e. from the 'kernel loading mid-stage
> bootloader' if you have such).

Hi, thanks a lot for the explanation! That makes sense, I'll try
implementing your suggestions and will report back :)

> 
>> 
>>> 
>>> Thanks,
>>> Robin.
>>> 
>>>> The commit has been introduced in mainline v6.15-rc1. I've also
>>>> tested in
>>>> v6.15, v6.15.2, and v6.16-rc2, and there have been no apparent 
>>>> changes.
>>>> 
>>>> I've tried to revert the commit, and it does work that way. But on
>>>> reading
>>>> the commit message I understand that I need to find a proper
>>>> solution here.
>>>> I've tried to skim down the revert, and this is what I get - if i
>>>> change
>>>> line [4] as follows:
>>>> 
>>>> -        dev->bus->dma_configure(dev);
>>>> +        if (!strcmp(dev_name(dev), "14830000.decon"))
>>>> +            dev->bus->dma_configure(dev);
>>>> 
>>>> It really doesn't like dma_configure for some reason. It works, but:
>>>> 
>>>> [    2.779291] exynos-decon 14830000.decon: late IOMMU probe at
>>>> driver bind, something fishy here!
>>>> 
>>>> I believe the IOMMU hardware doesn't like the fact that it is being
>>>> initialized/resumed too early. I formed this conclusion by comparing
>>>> the
>>>> logs:
>>>> 
>>>> mainline:
>>>> [    1.274575] I_HAVE_ADDED_THESE: SYSMMU: exynos_sysmmu_resume 
>>>> enter
>>>> [    2.859656] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_enable enter
>>>> [    2.864192] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_enable_clocks 
>>>> enter
>>>> [    2.869299] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000000 val
>>>> 0x00000007
>>>> [    2.875062] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_init_config 
>>>> enter
>>>> [    2.880006] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000004 val
>>>> 0x01100784
>>>> [    2.885819] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_set_ptbase enter
>>>> [    2.890677] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x0000000c val
>>>> 0x00044a14
>>>> [    2.896490] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_tlb_invalidate
>>>> enter
>>>> [    2.901695] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000010 val
>>>> 0x00000001
>>>> [    2.907507] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_enable_vid enter
>>>> [    2.912366] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000000 val
>>>> 0x00000005
>>>> [    2.912371] I_HAVE_ADDED_THESE: SYSMMU: exynos_sysmmu_irq enter
>>>> [    2.912836] [drm] Exynos DRM: using 14830000.decon device for DMA
>>>> mapping operations
>>>> [    2.918175] I_HAVE_ADDED_THESE: SYSMMU:
>>>> exynos_sysmmu_v5_get_fault_info enter
>>>> [    2.918182] I_HAVE_ADDED_THESE: SYSMMU: show_fault_information 
>>>> enter
>>>> [    2.918189] exynos-sysmmu 14860000.sysmmu: 14830000.decon: [READ]
>>>> PAGE FAULT occurred at 0x6715b3e0
>>>> [    2.918199] exynos-sysmmu 14860000.sysmmu: Page table base:
>>>> 0x0000000044a14000
>>>> [    2.918243] exynos-drm exynos-drm: bound 14830000.decon (ops
>>>> decon_component_ops)
>>>> [    2.922859] I_HAVE_ADDED_THESE: SYSMMU: section_entry enter
>>>> [    2.922864] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
>>>> [    2.922868] exynos-sysmmu 14860000.sysmmu:   Lv1 entry: 0x4205001
>>>> [    2.922877] Kernel panic - not syncing: Unrecoverable System MMU
>>>> Fault!
>>>> 
>>>> and with the patch above applied:
>>>> [    3.018478] [drm] Exynos DRM: using 14830000.decon device for DMA
>>>> mapping operations
>>>> [    3.025794] exynos-drm exynos-drm: bound 14830000.decon (ops
>>>> decon_component_ops)
>>>> [    3.058655] exynos-dsi 14800000.dsi:
>>>> [drm:samsung_dsim_host_attach] Attached td4300-panel device (lanes:4
>>>> bpp:24 mode-flags:0x23)
>>>> [    3.070189] exynos-drm exynos-drm: bound 14800000.dsi (ops
>>>> exynos_dsi_component_ops)
>>>> [    3.078506] [drm] Initialized exynos 1.1.0 for exynos-drm on 
>>>> minor 1
>>>> [    3.090747] I_HAVE_ADDED_THESE: SYSMMU: exynos_iommu_map enter
>>>> [    3.090845] I_HAVE_ADDED_THESE: SYSMMU: to_exynos_domain enter
>>>> [    3.093325] I_HAVE_ADDED_THESE: SYSMMU: section_entry enter
>>>> [    3.097662] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
>>>> [    3.102000] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
>>>> [    3.106337] I_HAVE_ADDED_THESE: SYSMMU: lv1set_section enter
>>>> [    3.110762] I_HAVE_ADDED_THESE: SYSMMU: exynos_iommu_set_pte 
>>>> enter
>>>> [    3.115726] I_HAVE_ADDED_THESE: SYSMMU: exynos_iommu_map enter
>>>> [    3.120317] I_HAVE_ADDED_THESE: SYSMMU: to_exynos_domain enter
>>>> [    3.124914] I_HAVE_ADDED_THESE: SYSMMU: section_entry enter
>>>> [    3.129240] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
>>>> [    3.133578] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
>>>> [    3.137916] I_HAVE_ADDED_THESE: SYSMMU: lv1set_section enter
>>>> [    3.142340] I_HAVE_ADDED_THESE: SYSMMU: exynos_iommu_set_pte 
>>>> enter
>>>> [         ...] (a lot of repetitions later)
>>>> [    4.322904] I_HAVE_ADDED_THESE: SYSMMU: section_entry enter
>>>> [    4.327230] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
>>>> [    4.331567] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
>>>> [    4.335905] I_HAVE_ADDED_THESE: SYSMMU: alloc_lv2entry enter
>>>> [    4.340329] I_HAVE_ADDED_THESE: SYSMMU: page_entry enter
>>>> [    4.344407] I_HAVE_ADDED_THESE: SYSMMU: lv2ent_offset enter
>>>> [    4.348744] I_HAVE_ADDED_THESE: SYSMMU: lv1ent_offset enter
>>>> [    4.353082] I_HAVE_ADDED_THESE: SYSMMU: lv2set_page enter
>>>> [    4.357246] I_HAVE_ADDED_THESE: SYSMMU: exynos_iommu_set_pte 
>>>> enter
>>>> [    4.362751] I_HAVE_ADDED_THESE: SYSMMU: exynos_sysmmu_resume 
>>>> enter
>>>> [    4.362767] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_enable enter
>>>> [    4.362771] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_enable_clocks 
>>>> enter
>>>> [    4.362777] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000000 val
>>>> 0x00000007
>>>> [    4.362782] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_init_config 
>>>> enter
>>>> [    4.362786] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000004 val
>>>> 0x01100784
>>>> [    4.362791] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_set_ptbase enter
>>>> [    4.362795] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x0000000c val
>>>> 0x00042a64
>>>> [    4.362799] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_tlb_invalidate
>>>> enter
>>>> [    4.362803] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000010 val
>>>> 0x00000001
>>>> [    4.362808] I_HAVE_ADDED_THESE: SYSMMU: __sysmmu_enable_vid enter
>>>> [    4.362811] I_HAVE_ADDED_THESE: SYSMMU: write: reg 0x00000000 val
>>>> 0x00000005
>>>> 
>>>> Then it continues booting as usual.
>>>> 
>>>> My lack of understanding of the IOMMU and DRM subsystems are really
>>>> limiting my triaging capabilities here, therefore I ask for any form
>>>> guidance or assistance with this.
>>>> 
>>>> Thank you.
>>>> 
>>>> [1]
>>>> https://lore.kernel.org/r/20250612-exynosdrm-decon-v2-0-d6c1d21c8057@disroot.org
>>>> [2]
>>>> https://lore.kernel.org/all/20250612-exynos7870-drm-dts-v1-2-88c0779af6cb@disroot.org
>>>> [3]
>>>> https://lore.kernel.org/all/20250612-exynos7870-drm-dts-v1-3-88c0779af6cb@disroot.org
>>>> [4]
>>>> https://protect2.fireeye.com/v1/url?k=015e6282-60d577b4-015fe9cd-74fe485cbff1-5039f5dfc286ac1d&q=1&e=4899b4fe-bcb8-43f2-87ed-92e79b0abe08&u=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv6.16-rc2%2Fsource%2Fdrivers%2Fiommu%2Fiommu.c%23L431
>> 
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland


More information about the dri-devel mailing list