Re: [PATCH v7 0/7] arm64: Default to 32-bit wide ZONE_DMA
Hi Matt, On 2022-03-01 03:00, Matt Flax wrote: Hi All, It seems that the ZONE_DMA changes have broken the operation of Rochip rk3399 chipsets from v5.10.22 onwards. It isn't clear what needs to be changed to get any of these boards up and running again. Any pointers on how/what to change ? Your firmware/bootloader setup is mismatched. If you're using the downstream Rockchip blob for BL31, you need to reserve or remove the memory range 0x840-0x960 to match the behaviour of the original Android BSP U-Boot. The downstream firmware firewalls this memory off for the Secure world such that any attempt to touch it from Linux results in a fatal SError fault as below. Any apparent correlation with the ZONE_DMA changes will simply be because they've affected the behaviour of the page allocator, such that it's more likely to reach into the affected range of memory. Cheers, Robin. An easy test for debugging is to run stress : stress --cpu 4 --io 4 --vm 2 --vm-bytes 128M stress: info: [255] dispatching hogs: 4 cpu, 4 io, 2 vm, 0 hdd [8.070280] SError Interrupt on CPU4, code 0xbf00 -- SError [8.070286] CPU: 4 PID: 261 Comm: stress Not tainted 5.10.21 #1 [8.070289] Hardware name: FriendlyElec NanoPi M4 (DT) [8.070293] pstate: 0005 (nzcv daif -PAN -UAO -TCO BTYPE=--) [8.070296] pc : clear_page+0x14/0x28 [8.070298] lr : clear_subpage+0x50/0x90 [8.070302] sp : 800012abbc40 [8.070305] x29: 800012abbc40 x28: 00f68000 [8.070313] x27: x26: 01f38e40 [8.070320] x25: 8000114fd000 x24: [8.070326] x23: x22: 1000 [8.070334] x21: a7e0 x20: fe01 [8.070341] x19: 00f68000 x18: [8.070348] x17: x16: [8.070354] x15: 0002 x14: 0001 [8.070361] x13: 00075879 x12: 00c0 [8.070368] x11: 80006c46a000 x10: 0200 [8.070374] x9 : x8 : 0010 [8.070381] x7 : 7db800a0 x6 : 800011b899c0 [8.070387] x5 : x4 : 7db800f7 [8.070394] x3 : 0220 x2 : 0004 [8.070401] x1 : 0040 x0 : 085ff4c0 [8.070409] Kernel panic - not syncing: Asynchronous SError Interrupt [8.070412] CPU: 4 PID: 261 Comm: stress Not tainted 5.10.21 #1 [8.070415] Hardware name: FriendlyElec NanoPi M4 (DT) [8.070418] Call trace: [8.070420] dump_backtrace+0x0/0x1b0 [8.070423] show_stack+0x18/0x70 [8.070425] dump_stack+0xd0/0x12c [8.070428] panic+0x16c/0x334 [8.070430] nmi_panic+0x8c/0x90 [8.070433] arm64_serror_panic+0x78/0x84 [8.070435] do_serror+0x64/0x70 [8.070437] el1_error+0x88/0x108 [8.070440] clear_page+0x14/0x28 [8.070443] clear_huge_page+0x74/0x210 [8.070445] do_huge_pmd_anonymous_page+0x1b0/0x7c0 [8.070448] handle_mm_fault+0xdac/0x1290 [8.070451] do_page_fault+0x130/0x3a0 [8.070453] do_translation_fault+0xb0/0xc0 [8.070456] do_mem_abort+0x44/0xb0 [8.070458] el0_da+0x28/0x40 [8.070461] el0_sync_handler+0x168/0x1b0 [8.070464] el0_sync+0x174/0x180 [8.070508] SError Interrupt on CPU0, code 0xbf00 -- SError [8.070511] CPU: 0 PID: 258 Comm: stress Not tainted 5.10.21 #1 [8.070515] Hardware name: FriendlyElec NanoPi M4 (DT) [8.070518] pstate: 8000 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [8.070520] pc : cec22e98 [8.070523] lr : cec22d84 [8.070525] sp : e67a8620 [8.070528] x29: e67a8620 x28: 0003 [8.070534] x27: cec34000 x26: aeb42610 [8.070541] x25: a69af010 x24: cec23a98 [8.070547] x23: cec35010 x22: cec35000 [8.070554] x21: 1000 x20: [8.070560] x19: 0800 x18: [8.070567] x17: x16: [8.070573] x15: x14: [8.070580] x13: 8000 x12: [8.070587] x11: 0020 x10: 0030 [8.070593] x9 : 000a x8 : 00de [8.070599] x7 : 0020 x6 : 021b [8.070606] x5 : x4 : [8.070613] x3 : x2 : aeb47000 [8.070619] x1 : 005a x0 : 00a58000 [8.070629] SMP: stopping secondary CPUs [8.070632] Kernel Offset: disabled [8.070634] CPU features: 0x0240022,6100600c [8.070637] Memory Limit: none ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 0/7] arm64: Default to 32-bit wide ZONE_DMA
Hi All, It seems that the ZONE_DMA changes have broken the operation of Rochip rk3399 chipsets from v5.10.22 onwards. It isn't clear what needs to be changed to get any of these boards up and running again. Any pointers on how/what to change ? An easy test for debugging is to run stress : stress --cpu 4 --io 4 --vm 2 --vm-bytes 128M stress: info: [255] dispatching hogs: 4 cpu, 4 io, 2 vm, 0 hdd [8.070280] SError Interrupt on CPU4, code 0xbf00 -- SError [8.070286] CPU: 4 PID: 261 Comm: stress Not tainted 5.10.21 #1 [8.070289] Hardware name: FriendlyElec NanoPi M4 (DT) [8.070293] pstate: 0005 (nzcv daif -PAN -UAO -TCO BTYPE=--) [8.070296] pc : clear_page+0x14/0x28 [8.070298] lr : clear_subpage+0x50/0x90 [8.070302] sp : 800012abbc40 [8.070305] x29: 800012abbc40 x28: 00f68000 [8.070313] x27: x26: 01f38e40 [8.070320] x25: 8000114fd000 x24: [8.070326] x23: x22: 1000 [8.070334] x21: a7e0 x20: fe01 [8.070341] x19: 00f68000 x18: [8.070348] x17: x16: [8.070354] x15: 0002 x14: 0001 [8.070361] x13: 00075879 x12: 00c0 [8.070368] x11: 80006c46a000 x10: 0200 [8.070374] x9 : x8 : 0010 [8.070381] x7 : 7db800a0 x6 : 800011b899c0 [8.070387] x5 : x4 : 7db800f7 [8.070394] x3 : 0220 x2 : 0004 [8.070401] x1 : 0040 x0 : 085ff4c0 [8.070409] Kernel panic - not syncing: Asynchronous SError Interrupt [8.070412] CPU: 4 PID: 261 Comm: stress Not tainted 5.10.21 #1 [8.070415] Hardware name: FriendlyElec NanoPi M4 (DT) [8.070418] Call trace: [8.070420] dump_backtrace+0x0/0x1b0 [8.070423] show_stack+0x18/0x70 [8.070425] dump_stack+0xd0/0x12c [8.070428] panic+0x16c/0x334 [8.070430] nmi_panic+0x8c/0x90 [8.070433] arm64_serror_panic+0x78/0x84 [8.070435] do_serror+0x64/0x70 [8.070437] el1_error+0x88/0x108 [8.070440] clear_page+0x14/0x28 [8.070443] clear_huge_page+0x74/0x210 [8.070445] do_huge_pmd_anonymous_page+0x1b0/0x7c0 [8.070448] handle_mm_fault+0xdac/0x1290 [8.070451] do_page_fault+0x130/0x3a0 [8.070453] do_translation_fault+0xb0/0xc0 [8.070456] do_mem_abort+0x44/0xb0 [8.070458] el0_da+0x28/0x40 [8.070461] el0_sync_handler+0x168/0x1b0 [8.070464] el0_sync+0x174/0x180 [8.070508] SError Interrupt on CPU0, code 0xbf00 -- SError [8.070511] CPU: 0 PID: 258 Comm: stress Not tainted 5.10.21 #1 [8.070515] Hardware name: FriendlyElec NanoPi M4 (DT) [8.070518] pstate: 8000 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [8.070520] pc : cec22e98 [8.070523] lr : cec22d84 [8.070525] sp : e67a8620 [8.070528] x29: e67a8620 x28: 0003 [8.070534] x27: cec34000 x26: aeb42610 [8.070541] x25: a69af010 x24: cec23a98 [8.070547] x23: cec35010 x22: cec35000 [8.070554] x21: 1000 x20: [8.070560] x19: 0800 x18: [8.070567] x17: x16: [8.070573] x15: x14: [8.070580] x13: 8000 x12: [8.070587] x11: 0020 x10: 0030 [8.070593] x9 : 000a x8 : 00de [8.070599] x7 : 0020 x6 : 021b [8.070606] x5 : x4 : [8.070613] x3 : x2 : aeb47000 [8.070619] x1 : 005a x0 : 00a58000 [8.070629] SMP: stopping secondary CPUs [8.070632] Kernel Offset: disabled [8.070634] CPU features: 0x0240022,6100600c [8.070637] Memory Limit: none -- 2.32.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v7 0/7] arm64: Default to 32-bit wide ZONE_DMA
Using two distinct DMA zones turned out to be problematic. Here's an attempt go back to a saner default. I tested this on both a RPi4 and QEMU. --- Changes since v6: - Update patch #1 so we reserve crashkernel before request_standard_resources() - Tested on top of Catalin's mem_init() patches. Changes since v5: - Unify ACPI/DT functions Changes since v4: - Fix of_dma_get_max_cpu_address() so it returns the last addressable addres, not the limit Changes since v3: - Drop patch adding define in dma-mapping - Address small review changes - Update Ard's patch - Add new patch removing examples from mmzone.h Changes since v2: - Introduce Ard's patch - Improve OF dma-ranges parsing function - Add unit test for OF function - Address small changes - Move crashkernel reservation later in boot process Changes since v1: - Parse dma-ranges instead of using machine compatible string Ard Biesheuvel (1): arm64: mm: Set ZONE_DMA size based on early IORT scan Nicolas Saenz Julienne (6): arm64: mm: Move reserve_crashkernel() into mem_init() arm64: mm: Move zone_dma_bits initialization into zone_sizes_init() of/address: Introduce of_dma_get_max_cpu_address() of: unittest: Add test for of_dma_get_max_cpu_address() arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges mm: Remove examples from enum zone_type comment arch/arm64/mm/init.c | 22 +--- drivers/acpi/arm64/iort.c | 55 +++ drivers/of/address.c | 42 ++ drivers/of/unittest.c | 18 + include/linux/acpi_iort.h | 4 +++ include/linux/mmzone.h| 20 -- include/linux/of.h| 7 + 7 files changed, 139 insertions(+), 29 deletions(-) -- 2.29.2 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
