Regression identified while booting the Dragonboard 410c (Qualcomm APQ8016 SBC) using the Linux next-20250702 kernel tag. During device initialization, the kernel triggers a WARNING in the arm_lpae_map_pages() function, which is part of the IOMMU subsystem. The call trace also involves qcom_iommu_map().
Test environments: - Dragonboard-410c
Regression Analysis: - New regression? Yes - Reproducibility? Yes
Boot regression: next-20250702 WARNING iommu io-pgtable-arm.c at arm_lpae_map_pages qcom_iommu_map
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
List of suspected patches with recent changes. * https://lore.kernel.org/all/0-v2-68a2e1ba507c+1fb-iommu_rm_ops_pgsize_jgg@nv...
## Boot log
[ 9.504700] ------------[ cut here ]------------ [ 9.509432] WARNING: drivers/iommu/io-pgtable-arm.c:569 at arm_lpae_map_pages+0x30/0x1cc, CPU#0: udev-worker)/216 [ 9.514301] Modules linked in: snd_soc_core venus_core(+) qrtr videobuf2_dma_sg qcom_q6v5_mss v4l2_fwnode snd_compress adv7511 llcc_qcom snd_pcm_dmaengine snd_pcm ocmem qcom_pil_info qcom_q6v5 v4l2_async drm_exec snd_timer qcom_sysmon v4l2_mem2mem gpu_sched videobuf2_memops snd videobuf2_v4l2 qcom_common drm_dp_aux_bus qcom_spmi_temp_alarm qcom_pon qcom_spmi_vadc drm_display_helper rtc_pm8xxx soundcore videodev qcom_glink_smem qcom_vadc_common mdt_loader cec qmi_helpers qnoc_msm8916 videobuf2_common drm_client_lib mc phy_qcom_usb_hs qcom_stats qcom_rng ramoops socinfo rpmsg_ctrl rmtfs_mem rpmsg_char display_connector reed_solomon drm_kms_helper fuse drm backlight ip_tables x_tables [ 9.562593] CPU: 0 UID: 0 PID: 216 Comm: (udev-worker) Not tainted 6.16.0-rc4-next-20250702 #1 PREEMPT [ 9.584779] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 9.594059] pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 9.601002] pc : arm_lpae_map_pages (drivers/iommu/io-pgtable-arm.c:569 (discriminator 7)) [ 9.607682] lr : qcom_iommu_map (drivers/iommu/arm/arm-smmu/qcom_iommu.c:441) [ 9.612196] sp : ffff800083a9b4e0 [ 9.616274] x29: ffff800083a9b4e0 x28: 0000000000000004 x27: 0000000000200000 [ 9.619579] x26: 0000000000000003 x25: ffff000004a2ec78 x24: ffff800083a9b550 [ 9.626698] x23: 0000000000000002 x22: 0000000000100000 x21: 000000008f400000 [ 9.633816] x20: 0000000000000000 x19: ffff000004a2eb48 x18: 0000000000000000 [ 9.640934] x17: ffff000003807000 x16: ffff000003806e00 x15: ffff000004a2ec78 [ 9.648051] x14: ffff000003ef8000 x13: 0000000000000001 x12: ffff000004a2ec10 [ 9.655170] x11: 0000000000000004 x10: 0000000000000820 x9 : 0000000000000000 [ 9.662287] x8 : ffff8000809fe7a4 x7 : ffff800083a9b550 x6 : 0000000000001000 [ 9.669406] x5 : 0000000000000003 x4 : 0000000000000002 x3 : 0000000000100000 [ 9.676530] x2 : 000000008f400000 x1 : 00000000dd800000 x0 : ffff000004a2ec00 [ 9.683643] Call trace: [ 9.690752] arm_lpae_map_pages (drivers/iommu/io-pgtable-arm.c:569 (discriminator 7)) (P) [ 9.693013] iommu_map_nosync (drivers/iommu/iommu.c:2505) [ 9.697524] iommu_map_sg (drivers/iommu/iommu.c:2677) [ 9.701604] __iommu_dma_alloc_noncontiguous (drivers/iommu/dma-iommu.c:982) [ 9.705253] iommu_dma_alloc (drivers/iommu/dma-iommu.c:1006 drivers/iommu/dma-iommu.c:1650) [ 9.710546] dma_alloc_attrs (kernel/dma/mapping.c:638) [ 9.714452] venus_hfi_create+0xa8/0x248 venus_core [ 9.718015] hfi_create+0x54/0x6c venus_core [ 9.723221] venus_probe+0x254/0x574 venus_core [ 9.727563] platform_probe (drivers/base/platform.c:1404) [ 9.732333] really_probe (drivers/base/dd.c:579 drivers/base/dd.c:657) [ 9.735979] __driver_probe_device (drivers/base/dd.c:799) [ 9.739626] driver_probe_device (drivers/base/dd.c:829) [ 9.743879] __driver_attach (drivers/base/dd.c:1216 drivers/base/dd.c:1155) [ 9.747871] bus_for_each_dev (drivers/base/bus.c:370) [ 9.751690] driver_attach (drivers/base/dd.c:1234) [ 9.755510] bus_add_driver (drivers/base/bus.c:678) [ 9.759330] driver_register (drivers/base/driver.c:249) [ 9.762889] __platform_driver_register (drivers/base/platform.c:868) [ 9.766623] qcom_venus_driver_init+0x20/0xfc0 venus_core [ 9.771486] do_one_initcall (init/main.c:1269) [ 9.776865] do_init_module (kernel/module/main.c:3046) [ 9.780685] load_module (kernel/module/main.c:3516) [ 9.784503] init_module_from_file (kernel/module/main.c:3709) [ 9.788237] __arm64_sys_finit_module (kernel/module/main.c:3720 kernel/module/main.c:3746 kernel/module/main.c:3730 kernel/module/main.c:3730) [ 9.792668] invoke_syscall (arch/arm64/include/asm/current.h:19 arch/arm64/kernel/syscall.c:54) [ 9.797264] el0_svc_common.constprop.0 (arch/arm64/kernel/syscall.c:139) [ 9.800911] do_el0_svc (arch/arm64/kernel/syscall.c:152) [ 9.805683] el0_svc (arch/arm64/include/asm/irqflags.h:55 arch/arm64/include/asm/irqflags.h:76 arch/arm64/kernel/entry-common.c:169 arch/arm64/kernel/entry-common.c:182 arch/arm64/kernel/entry-common.c:772) [ 9.808982] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:791) [ 9.811934] el0t_64_sync (arch/arm64/kernel/entry.S:600) [ 9.816362] ---[ end trace 0000000000000000 ]---
## Source * Kernel version: 6.16.0-rc4-next-20250702 * Git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git * Git sha: 50c8770a42faf8b1c7abe93e7c114337f580a97d * Git describe: next-20250702 * Project: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250702 * Architectures: arm64 * Toolchains: gcc-13 * Kconfigs: gcc-13-lkftconfig
## Build * Test log: https://qa-reports.linaro.org/api/testruns/28989497/log_file/ * Test LAVA log: https://lkft.validation.linaro.org/scheduler/job/8339869#L3862 * Test details: https://regressions.linaro.org/lkft/linux-next-master/next-20250702/boot/gcc... * Test plan: https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2zJgUBCVJbq... * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2zJgRgltAwUHEijfEA14M... * Kernel config: https://storage.tuxsuite.com/public/linaro/lkft/builds/2zJgRgltAwUHEijfEA14M...
-- Linaro LKFT https://lkft.linaro.org
On Wed, Jul 09, 2025 at 02:26:20AM +0530, Naresh Kamboju wrote:
Regression identified while booting the Dragonboard 410c (Qualcomm APQ8016 SBC) using the Linux next-20250702 kernel tag. During device initialization, the kernel triggers a WARNING in the arm_lpae_map_pages() function, which is part of the IOMMU subsystem. The call trace also involves qcom_iommu_map().
Test environments:
- Dragonboard-410c
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Boot regression: next-20250702 WARNING iommu io-pgtable-arm.c at arm_lpae_map_pages qcom_iommu_map
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
List of suspected patches with recent changes.
Can you test this fix please:
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c @@ -229,7 +229,7 @@ static int qcom_iommu_init_domain(struct iommu_domain *domain, goto out_unlock;
pgtbl_cfg = (struct io_pgtable_cfg) { - .pgsize_bitmap = domain->pgsize_bitmap, + .pgsize_bitmap = SZ_4K | SZ_64K | SZ_1M | SZ_16M, .ias = 32, .oas = 40, .tlb = &qcom_flush_ops, @@ -246,6 +246,8 @@ static int qcom_iommu_init_domain(struct iommu_domain *domain, goto out_clear_iommu; }
+ /* Update the domain's page sizes to reflect the page table format */ + domain->pgsize_bitmap = pgtbl_cfg.pgsize_bitmap; domain->geometry.aperture_end = (1ULL << pgtbl_cfg.ias) - 1; domain->geometry.force_aperture = true;
@@ -335,7 +337,6 @@ static struct iommu_domain *qcom_iommu_domain_alloc_paging(struct device *dev)
mutex_init(&qcom_domain->init_mutex); spin_lock_init(&qcom_domain->pgtbl_lock); - qcom_domain->domain.pgsize_bitmap = SZ_4K | SZ_64K | SZ_1M | SZ_16M;
return &qcom_domain->domain; }
Of all the drivers qcom is the only one that uses the 64 bit arm page table, 4 & 64k sizes, and was using the ops global. The io_pgtable code will remove one of the two depending on PAGE_SIZE which makes things inconsistent and hits that warn.
Jason
On Wed, 9 Jul 2025 at 05:55, Jason Gunthorpe jgg@nvidia.com wrote:
On Wed, Jul 09, 2025 at 02:26:20AM +0530, Naresh Kamboju wrote:
Regression identified while booting the Dragonboard 410c (Qualcomm APQ8016 SBC) using the Linux next-20250702 kernel tag. During device initialization, the kernel triggers a WARNING in the arm_lpae_map_pages() function, which is part of the IOMMU subsystem. The call trace also involves qcom_iommu_map().
Test environments:
- Dragonboard-410c
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Boot regression: next-20250702 WARNING iommu io-pgtable-arm.c at arm_lpae_map_pages qcom_iommu_map
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
List of suspected patches with recent changes.
Can you test this fix please:
I have tested this patch on top of Linux next-20250702 tag, and found kernel warning,
[ 1.510468] ------------[ cut here ]------------ [ 1.516302] WARNING: drivers/iommu/iommu.c:1142 at iommu_create_device_direct_mappings+0x240/0x258, CPU#1: swapper/0/1 [ 1.521001] Modules linked in: [ 1.531485] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0-rc4-next-20250702 #1 PREEMPT [ 1.534538] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 1.543473] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.550241] pc : iommu_create_device_direct_mappings (drivers/iommu/iommu.c:1142 (discriminator 7)) [ 1.556924] lr : iommu_setup_default_domain (drivers/iommu/iommu.c:2992 (discriminator 1)) [ 1.563170] sp : ffff80008002b9c0 [ 1.568113] x29: ffff80008002b9e0 x28: 0000000000000000 x27: ffff80008174e2c0 [ 1.571596] x26: ffff000004c58030 x25: ffff800081d75228 x24: ffff80008221eba4 [ 1.578714] x23: ffff000003d99410 x22: ffff80008002b9c8 x21: ffff000003ce5900 [ 1.585833] x20: ffff000003ce5948 x19: ffff000002e6d5a0 x18: 0000000000000000 [ 1.592951] x17: ffff000003d4a000 x16: ffff000002c37e00 x15: 07690720076f0774 [ 1.600068] x14: 0000000000000000 x13: ffff800082237670 x12: 000000000003786e [ 1.607185] x11: 0000000000000115 x10: 0000000000103758 x9 : 0000000000000000 [ 1.614303] x8 : ffff000003ce5d00 x7 : 0000000000000000 x6 : 000000000000003f [ 1.621422] x5 : 0000000000000040 x4 : 0000000000000000 x3 : 0000000000000001 [ 1.628539] x2 : ffff000002ce0000 x1 : ffff000003d99410 x0 : 0000000000000003 [ 1.635660] Call trace: [ 1.642766] iommu_create_device_direct_mappings (drivers/iommu/iommu.c:1142 (discriminator 7)) (P) [ 1.645031] iommu_setup_default_domain (drivers/iommu/iommu.c:2992 (discriminator 1)) [ 1.651277] iommu_device_register (drivers/iommu/iommu.c:1905 drivers/iommu/iommu.c:277) [ 1.655877] qcom_iommu_device_probe (drivers/iommu/arm/arm-smmu/qcom_iommu.c:860) [ 1.660392] platform_probe (drivers/base/platform.c:1404) [ 1.665163] really_probe (drivers/base/dd.c:579 drivers/base/dd.c:657) [ 1.668723] __driver_probe_device (drivers/base/dd.c:799) [ 1.672371] driver_probe_device (drivers/base/dd.c:829) [ 1.676623] __driver_attach (drivers/base/dd.c:1216 drivers/base/dd.c:1155) [ 1.680615] bus_for_each_dev (drivers/base/bus.c:370) [ 1.684434] driver_attach (drivers/base/dd.c:1234) [ 1.688255] bus_add_driver (drivers/base/bus.c:678) [ 1.692073] driver_register (drivers/base/driver.c:249) [ 1.695633] __platform_driver_register (drivers/base/platform.c:868) [ 1.699368] qcom_iommu_init (drivers/iommu/arm/arm-smmu/qcom_iommu.c:943) [ 1.704226] do_one_initcall (init/main.c:1269) [ 1.707873] kernel_init_freeable (init/main.c:1330 (discriminator 1) init/main.c:1347 (discriminator 1) init/main.c:1366 (discriminator 1) init/main.c:1579 (discriminator 1)) [ 1.711607] kernel_init (init/main.c:1473) [ 1.716118] ret_from_fork (arch/arm64/kernel/entry.S:863) [ 1.719419] ---[ end trace 0000000000000000 ]--- [ 1.723302] iommu 1ef0000.iommu: IOMMU driver was not able to establish FW requested direct mapping. [ 1.734231] platform 1c00000.gpu: Adding to iommu group 2 [ 1.748218] loop: module loaded
Links: - https://lkft.validation.linaro.org/scheduler/job/8350682#L2838
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c @@ -229,7 +229,7 @@ static int qcom_iommu_init_domain(struct iommu_domain *domain, goto out_unlock;
pgtbl_cfg = (struct io_pgtable_cfg) {
.pgsize_bitmap = domain->pgsize_bitmap,
.pgsize_bitmap = SZ_4K | SZ_64K | SZ_1M | SZ_16M, .ias = 32, .oas = 40, .tlb = &qcom_flush_ops,@@ -246,6 +246,8 @@ static int qcom_iommu_init_domain(struct iommu_domain *domain, goto out_clear_iommu; }
/* Update the domain's page sizes to reflect the page table format */domain->pgsize_bitmap = pgtbl_cfg.pgsize_bitmap; domain->geometry.aperture_end = (1ULL << pgtbl_cfg.ias) - 1; domain->geometry.force_aperture = true;@@ -335,7 +337,6 @@ static struct iommu_domain *qcom_iommu_domain_alloc_paging(struct device *dev)
mutex_init(&qcom_domain->init_mutex); spin_lock_init(&qcom_domain->pgtbl_lock);
qcom_domain->domain.pgsize_bitmap = SZ_4K | SZ_64K | SZ_1M | SZ_16M; return &qcom_domain->domain;}
Of all the drivers qcom is the only one that uses the 64 bit arm page table, 4 & 64k sizes, and was using the ops global. The io_pgtable code will remove one of the two depending on PAGE_SIZE which makes things inconsistent and hits that warn.
Jason
On Wed, Jul 09, 2025 at 04:14:26PM +0530, Naresh Kamboju wrote:
I have tested this patch on top of Linux next-20250702 tag, and found kernel warning,
Oh, yeah, I guess that hacky fix is not going to work.
Then this is probably good enough (against linux-next):
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c @@ -335,7 +335,7 @@ static struct iommu_domain *qcom_iommu_domain_alloc_paging(struct device *dev)
mutex_init(&qcom_domain->init_mutex); spin_lock_init(&qcom_domain->pgtbl_lock); - qcom_domain->domain.pgsize_bitmap = SZ_4K | SZ_64K | SZ_1M | SZ_16M; + qcom_domain->domain.pgsize_bitmap = SZ_4K | SZ_2M;
return &qcom_domain->domain; }
I believe the original text was a copy and pasto from an ARMv7s driver (ie the 32 bit ARM page table) which uses that unique combination of sizes. It is not a sane bitmap for HW with 64 bit page table support, there is never a 1M option for instance.
So this removes 64k page support, which maybe didn't even work?
I also prepared a proper rework that puts the pgtable allocation into the qcom_iommu_domain_alloc_paging(). I've attached it, but it is involved enough it probably breaks something else. However if you want to test it maybe we can progress it too.
Thanks, Jason
On Wed, Jul 9, 2025, at 18:26, Jason Gunthorpe wrote:
On Wed, Jul 09, 2025 at 04:14:26PM +0530, Naresh Kamboju wrote:
I believe the original text was a copy and pasto from an ARMv7s driver (ie the 32 bit ARM page table) which uses that unique combination of sizes. It is not a sane bitmap for HW with 64 bit page table support, there is never a 1M option for instance.
So this removes 64k page support, which maybe didn't even work?
My guess would be that this bug is specific to this SoC running in 32-bit mode. This is a rare exception and not really well supported, as most 64-bit Arm chips require a 64-bit kernel, but this one (along with Broadcom bcm283x) can do either.
When running a 32-bit kernel, there is definitely no support for 64KB pages in the CPU, unlike on arm64.
Arnd
On Wed, Jul 09, 2025 at 06:50:02PM +0200, Arnd Bergmann wrote:
On Wed, Jul 9, 2025, at 18:26, Jason Gunthorpe wrote:
On Wed, Jul 09, 2025 at 04:14:26PM +0530, Naresh Kamboju wrote:
I believe the original text was a copy and pasto from an ARMv7s driver (ie the 32 bit ARM page table) which uses that unique combination of sizes. It is not a sane bitmap for HW with 64 bit page table support, there is never a 1M option for instance.
So this removes 64k page support, which maybe didn't even work?
My guess would be that this bug is specific to this SoC running in 32-bit mode.
Sorry, it was unclear.
This driver always uses the ARM page table format with 64 bit entries. It uses the ARM_32_LPAE_S1 sub-flavour of it.
This is different from the ARM page table format with 32 bit entries called ARM_V7S. Only this format uses the 'SZ_4K | SZ_64K | SZ_1M | SZ_16M' bitmap.
Looking more closely when a driver selects ARM_32_LPAE_S1 it calls arm_32_lpae_alloc_pgtable_s1() which does:
cfg->pgsize_bitmap &= (SZ_4K | SZ_2M | SZ_1G);
So the 1 line patch looks OKish (maybe drop the SZ_2M to be conservative), despite putting it in the bitmap 64K would have never be used in the iommu no matter what the CPU is doing.
Jason
On Wed, 9 Jul 2025 at 21:56, Jason Gunthorpe jgg@nvidia.com wrote:
On Wed, Jul 09, 2025 at 04:14:26PM +0530, Naresh Kamboju wrote:
I have tested this patch on top of Linux next-20250702 tag, and found kernel warning,
Oh, yeah, I guess that hacky fix is not going to work.
Then this is probably good enough (against linux-next):
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c @@ -335,7 +335,7 @@ static struct iommu_domain *qcom_iommu_domain_alloc_paging(struct device *dev)
mutex_init(&qcom_domain->init_mutex); spin_lock_init(&qcom_domain->pgtbl_lock);
qcom_domain->domain.pgsize_bitmap = SZ_4K | SZ_64K | SZ_1M | SZ_16M;
qcom_domain->domain.pgsize_bitmap = SZ_4K | SZ_2M; return &qcom_domain->domain;}
I have tested the above patch and it fixes the reported issue.
Tested-by: Linux Kernel Functional Testing lkft@linaro.org
* https://lkft.validation.linaro.org/scheduler/job/8351756#L2565
-- Linaro LKFT https://lkft.linaro.org
-
Arnd Bergmann -
Jason Gunthorpe -
Naresh Kamboju