Annoying AMDGPU boot-time warning due to simplefb / amdgpu resource clash

[Thomas Zimmermann]

Hi

Am 26.06.22 um 20:54 schrieb Linus Torvalds:
> So this has been going on for a while, and it's quite annoying.
> 
> At bootup, my main desktop (Threadripper 3970X with radeon graphics)
> now complains about
> 
>    resource sanity check: requesting [mem 0xd0000000-0xdfffffff], which
> spans more than BOOTFB [mem 0xd0000000-0xd02fffff]
> 
> and then gives me a nasty callchain that is basically the amdgpu probe
> sequence ending in amdgpu_bo_init() doing the
> arch_io_reserve_memtype_wc() which is then what complains.
> 
> That "BOOTFB" resource is from sysfb_simplefb.c, and I think what
> started triggering this is commit c96898342c38 ("drivers/firmware:
> Don't mark as busy the simple-framebuffer IO resource").
> 
> Because it turns out that that removed the IORESOURCE_BUSY, which in
> turn is what makes the resource conflict code complain about it now,
> because
> 
>                  /*
>                   * if a resource is "BUSY", it's not a hardware resource
>                   * but a driver mapping of such a resource; we don't want
>                   * to warn for those; some drivers legitimately map only
>                   * partial hardware resources. (example: vesafb)
>                   */
> 
> so the issue is that now the resource code - correctly - says "hey,
> you have *two* conflicting driver mappings".
> 
> And that commit claims it did it because "which can lead to drivers
> requesting the same memory resource to fail", but - once again - the
> link in the commit that might actually tell more is just one of those
> useless patch submission links again.
> 
> So who knows why that commit was actually done, but it's causing annoyance.
> 
> If simplefb is actually still using that frame buffer, it's a problem.
> If it isn't, then maybe that resource should have been released?

As Javier said, that resource is the framebuffer that's set up by the 
firmware. It should be gone after the call to 
drm_aperture_remove_conflicting_pci_framebuffers(). [1] The call to 
amdgpu_bo_init() runs afterwards, so that removal apparently failed.

Is the BOOTFB entry still listed in /proc/iomem after the system 
finished booting?

Attached is a (totally untested) patch to manually point amdgpu to the 
right location. Does it fix the problem?

Best regards
Thomas

[1] 
https://elixir.bootlin.com/linux/v5.18.7/source/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c#L2077

> 
> I really think that commit c96898342c38 is buggy. It talks about "let
> drivers to request it as busy instead", but then it registers a
> resource that isn't actually a proper real resource. It's just a
> random incomplete chunk of the actual real thing, so it will still
> interfere with resource allocation, and in fact now interferes even
> with that "set memtype" because of this valid warning.
> 
>               Linus

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-drm-amdgpu-Remove-firmware-framebuffer-without-PCI-h.patch
Type: text/x-patch
Size: 1192 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20220627/a1613005/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20220627/a1613005/attachment.sig>