I have looked into this issue in more detail. It seems we have 2 separate issues.
- smmu warning is just a warning. Not a problem for now. But it could be in the future since it is deprecated (when the upstream removes support for this). Even then we might be able to fix the issue by modifying the device tree bindings in kernel. What can go wrong if this doesn't work? graphics/network cards that directly writes to cpu memory can corrupt it since the virtual memory doesn't work. - The real issue was simple-framebuffer error, where there is a conflict with initial memory ranges in kernel and where simple- framebuffer wants to reserve. This could still be related to firmware because that is where parameters to simple-framebuffer is passed from such as memory addresses. [ 8.185280] simple-framebuffer simple-framebuffer.0: [drm] could not acquire memory region [mem 0x10000000-0x102fffff flags 0x200] [ 8.197072] ------------[ cut here ]------------ [ 8.201690] WARNING: CPU: 5 PID: 1 at arch/arm64/mm/ioremap.c:16 ioremap_prot+0x84/0xa0 [ 8.209703] Modules linked in: [ 8.212759] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 6.8.0-90-lowlatency #91.1~22.04.1-Ubuntu [ 8.221372] Hardware name: GIGABYTE R120-T33/MT30-GS1, BIOS T31 02/14/2017 [ 8.228244] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 8.235205] pc : ioremap_prot+0x84/0xa0 [ 8.239039] lr : ioremap_prot+0x48/0xa0 [ 8.242873] sp : ffff800083aab810 [ 8.246183] x29: ffff800083aab810 x28: ffff000106394000 x27: 0000000000001000 [ 8.253325] x26: ffff000106394000 x25: 0000000000000400 x24: 0000000000000000 [ 8.260468] x23: 0000000010000000 x22: 0000000000300000 x21: 006800000000070b [ 8.267609] x20: 0000000000300000 x19: 0000000010000000 x18: ffff800083a750a8 [ 8.274752] x17: 0000000000000000 x16: 0000000000000000 x15: 072007200720075d [ 8.281894] x14: 0000000000000000 x13: 0000000000000020 x12: 0101010101010101 [ 8.289036] x11: 7f7f7f7f7f7f7f7f x10: 0000000000001bd0 x9 : ffff800080044358 [ 8.296178] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 8.303319] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 8.310460] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 [ 8.317602] Call trace: [ 8.320044] ioremap_prot+0x84/0xa0 [ 8.323532] devm_ioremap_wc+0x84/0x130 [ 8.327368] simpledrm_device_create.constprop.0+0x80c/0xad0 [ 8.333032] simpledrm_probe+0x20/0xb8 [ 8.336780] platform_probe+0x74/0x110 [ 8.340530] really_probe+0x1bc/0x420 [ 8.344190] __driver_probe_device+0x94/0x1d8 [ 8.348545] driver_probe_device+0x48/0x188 [ 8.352726] __device_attach_driver+0x114/0x220 [ 8.357254] bus_for_each_drv+0x94/0x118 [ 8.361178] __device_attach+0xac/0x208 [ 8.365012] device_initial_probe+0x20/0x48 [ 8.369193] bus_probe_device+0xcc/0xd8 [ 8.373028] device_add+0x568/0x770 [ 8.376515] platform_device_add+0x1c4/0x2b0 [ 8.380784] sysfb_create_simplefb+0x1a8/0x1c0 [ 8.385229] sysfb_init+0x184/0x1c8 [ 8.388715] do_one_initcall+0x68/0x3c0 [ 8.392550] do_initcalls+0x144/0x2f0 [ 8.396211] kernel_init_freeable+0x130/0x2b8 [ 8.400566] kernel_init+0x3c/0x250 [ 8.404055] ret_from_fork+0x10/0x20 After firmware/bios update on arm_server:mogino noble/jammy-hwe/questing kernels no longer had simple-framebuffer error. The older series were not affected by the change so it is safe to update. We need to take into consideration only one thing here. These machines are certified for xenial. We should not do anything to break xenial (https://ubuntu.com/certified/201710-25851). Additionally, since these are headless servers, simple-framebuffer issue doesn't have much effect in reality. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2088458 Title: noble/jammy arm-smmu and firmware discrepancy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2088458/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
