All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: "Linus Torvalds" <torvalds@linux-foundation.org>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Javier Martinez Canillas" <javierm@redhat.com>,
	"Zack Rusin" <zackr@vmware.com>,
	"Hans de Goede" <hdegoede@redhat.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>
Subject: Re: Annoying AMDGPU boot-time warning due to simplefb / amdgpu resource clash
Date: Mon, 27 Jun 2022 10:56:31 +0200	[thread overview]
Message-ID: <077b67c3-20f2-5137-2cad-7b3a832a4779@suse.de> (raw)
In-Reply-To: <CAHk-=wh42rU5mKU6=PCK5tdkYjh7r31dGNmYdHwqpFnRFvVudA@mail.gmail.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 3090 bytes --]

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

[-- Attachment #1.1.2: 0001-drm-amdgpu-Remove-firmware-framebuffer-without-PCI-h.patch --]
[-- Type: text/x-patch, Size: 1192 bytes --]

From c37f0fa8e763c471ddaccc08da9ec9bb1a715451 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann <tzimmermann@suse.de>
Date: Mon, 27 Jun 2022 10:51:44 +0200
Subject: [PATCH] drm/amdgpu: Remove firmware framebuffer without PCI helper

The DRM aperture helper for PCI devices fails to remove the firmware
framebuffer's device. Manually tell it where to look.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 46ef57b07c15..e00318ff66ff 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -2073,7 +2073,8 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
 	is_fw_fb = amdgpu_is_fw_framebuffer(base, size);
 
 	/* Get rid of things like offb */
-	ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, &amdgpu_kms_driver);
+	ret = drm_aperture_remove_conflicting_framebuffers(base, size, is_fw_fb,
+							   &amdgpu_kms_driver);
 	if (ret)
 		return ret;
 
-- 
2.36.1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

      parent reply	other threads:[~2022-06-27  8:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-26 18:54 Annoying AMDGPU boot-time warning due to simplefb / amdgpu resource clash Linus Torvalds
2022-06-27  8:02 ` Javier Martinez Canillas
2022-06-27 17:25   ` Linus Torvalds
2022-06-27 17:25     ` Linus Torvalds
2022-06-28  8:43     ` Thomas Zimmermann
2022-06-28 12:41       ` Jocelyn Falempe
2022-06-29  8:20         ` Javier Martinez Canillas
2022-06-27  8:56 ` Thomas Zimmermann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=077b67c3-20f2-5137-2cad-7b3a832a4779@suse.de \
    --to=tzimmermann@suse.de \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hdegoede@redhat.com \
    --cc=javierm@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=zackr@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.