[SRU][Kinetic][PATCH 1/1] UBUNTU: SAUCE: Revert "video/aperture: Disable and unregister sysfb devices via aperture helpers"
Kai-Heng Feng
kai.heng.feng at canonical.com
Fri Apr 21 00:45:41 UTC 2023
On Thu, Apr 20, 2023 at 8:22 AM Matthew Ruffell
<matthew.ruffell at canonical.com> wrote:
>
> BugLink: https://bugs.launchpad.net/bugs/2007001
>
> This reverts commit 89314ff239e1933357419fa91b20190150f114a8 (ubuntu-kinetic).
>
> Numerous VMWare users have reported that vmwgfx cannot reserve the memory
> region for the graphics framebuffer, leading their VMs to have blank screens.
>
> They see the following in dmesg:
>
> [ 11.135360] vmwgfx 0000:00:0f.0: BAR 2: can't reserve [mem 0x70000000-0x77ffffff 64bit pref]
> [ 11.135366] vmwgfx: probe of 0000:00:0f.0 failed with error -16
>
> And a cat /proc/iomem shows this:
>
> 50000000-7fffffff : PCI Bus 0000:00
> 70000000-77ffffff : 0000:00:0f.0
> 70000000-702fffff : BOOTFB
>
> The kernel has failed to release this memory region for vmwgfx to occupy.
>
> "video/aperture: Disable and unregister sysfb devices via aperture helpers" is
> a part of a much larger series that refactors device ownership, and this commit
> requires the whole series to be applied to work correctly. The whole series is
> large, has numerous fixups, and is not suitable for a stable kernel in the first
> place, as it does not fix any specific issue.
>
> Hence, reverting is the best way to fix this.
The commit in question fixes "drm/aperture: Run fbdev removal before
internal helpers", which is also reported and tested by VMware.
Maybe backporting the whole series is more reasonable?
Kai-Heng
>
> Signed-off-by: Matthew Ruffell <matthew.ruffell at canonical.com>
> ---
> drivers/gpu/drm/drm_aperture.c | 14 --------------
> drivers/video/fbdev/core/fbmem.c | 12 ++++++++++++
> 2 files changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
> index 528e2544661c..059fd71424f6 100644
> --- a/drivers/gpu/drm/drm_aperture.c
> +++ b/drivers/gpu/drm/drm_aperture.c
> @@ -7,7 +7,6 @@
> #include <linux/pci.h>
> #include <linux/platform_device.h> /* for firmware helpers */
> #include <linux/slab.h>
> -#include <linux/sysfb.h>
> #include <linux/types.h>
> #include <linux/vgaarb.h>
>
> @@ -293,20 +292,7 @@ int drm_aperture_remove_conflicting_framebuffers(resource_size_t base, resource_
> #if IS_REACHABLE(CONFIG_FB)
> struct apertures_struct *a;
> int ret;
> -#endif
> -
> - /*
> - * If a driver asked to unregister a platform device registered by
> - * sysfb, then can be assumed that this is a driver for a display
> - * that is set up by the system firmware and has a generic driver.
> - *
> - * Drivers for devices that don't have a generic driver will never
> - * ask for this, so let's assume that a real driver for the display
> - * was already probed and prevent sysfb to register devices later.
> - */
> - sysfb_disable();
>
> -#if IS_REACHABLE(CONFIG_FB)
> a = alloc_apertures(1);
> if (!a)
> return -ENOMEM;
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 959fa1948f29..bc5a9154783d 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -19,6 +19,7 @@
> #include <linux/kernel.h>
> #include <linux/major.h>
> #include <linux/slab.h>
> +#include <linux/sysfb.h>
> #include <linux/mm.h>
> #include <linux/mman.h>
> #include <linux/vt.h>
> @@ -1768,6 +1769,17 @@ int remove_conflicting_framebuffers(struct apertures_struct *a,
> do_free = true;
> }
>
> + /*
> + * If a driver asked to unregister a platform device registered by
> + * sysfb, then can be assumed that this is a driver for a display
> + * that is set up by the system firmware and has a generic driver.
> + *
> + * Drivers for devices that don't have a generic driver will never
> + * ask for this, so let's assume that a real driver for the display
> + * was already probed and prevent sysfb to register devices later.
> + */
> + sysfb_disable();
> +
> mutex_lock(®istration_lock);
> do_remove_conflicting_framebuffers(a, name, primary);
> mutex_unlock(®istration_lock);
> --
> 2.39.2
>
>
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
More information about the kernel-team
mailing list