Hi Christian, On Thu, Jul 16, 2026 at 2:34 AM Christian König <[email protected]> wrote: > > Hi Anirudh, > > On 7/16/26 04:08, Anirudh Srinivasan wrote: > > Hi Christian, > > > > On Wed, Jul 15, 2026 at 4:15 AM Christian König > > <[email protected]> wrote: > >> > >> On 7/14/26 18:03, Anirudh Srinivasan wrote: > >>> radeon fails to probe on platforms that have all their memory above the > >>> 32-bit range with an -ENOMEM because dummy_page_init calls > >>> alloc_page(GFP_DMA32), which would fail. > >> > >> Unfortunately I clearly have to reject this. > >> > >> The DMA32 allocation is mandatory for radeon to work correctly on some > >> platforms. > >> > >>> Allow this driver to work on such platforms by falling back to > >>> ZONE_NORMAL regions. dma_map_page called subsequently would catch any > >>> issues with the device being unable to DMA into the mapped page. > >> > >> No, it doesn't. > >> > >> It's just your special case that dma_map_page() is able to use some IOMMU > >> to remap the page below 32bits so that the driver can access it. > >> > >> The problem is that we have quite a bunch of cases where this doesn't work > >> correctly and eventually result in all kinds of trouble, including random > >> memory corruptions. > >> > >> In those cases it's better to not load the driver at all than to later > >> deal with corrupted data. > > > > So this platform has an IOMMU, but it isn't enabled in the upstream > > kernel at the moment. I am able to boot up to framebuffer console. > > That is not even remotely enough to actually test the driver. > > What happens is that you allocation succeeds, but you simply doesn't exercise > the functionality which would need the dummy page. > > > Is there anything that isn't expected to work in this setup? Is there > > some test I can run to verify this? > > For the technical background, the dummy page is there to prevent buggy > applications/driver code to crash the system. > > The general idea is that a reads/writes which otherwise would go into nirvana > are redirected to the dummy page and so prevented from harming the system as > a whole. > > The problem is that while some HW generations can handle 40bit of PCI > addresses the dummy page register is only 32bit wide in some cases (I would > need to double check your specific HW generation, maybe that would help). > > To actually make sure everything works as expected you need to enable some > desktop system and run OpenGL tests. If then an error occurs and IOMMU > confirms that the right address is used for the dummy write then we could be > save that this actually works.
Thanks for explaining what the dummy page is used for. I will try running some OpenGL tests with/without the IOMMU and see what happens. It'll probably be a while till I can test this since the IOMMU isn't enabled in upstream kernels yet. > > > I should look into whether the IOMMU on this cihp can be enabled and > > then try this out too. > > Well enabling IOMMU could eventually help, but the code in the current form > would still fail. You need to use something like dma_alloc_coherent() and I > think that this won't work because of the HW restrictions. > > >> > >> What could be possible is to add a special quirk for your platform to not > >> allocate the dummy page as DMA32 in the first place. > > > > So some kind of a whitelisted set of PCIE vendor/ID combos (with > > working IOMMUS?) where we fallback to non DMA32 ranges? > > No, what you are testing here is basically that display is functional and not > anything else. I think I understand this now. You're suggesting that we skip allocating the dummy page in this specific case. > > Regards, > Christian. > > > > > Regards > > Anirudh Srinivasan >
