Re: [PATCH 10/13] drm/amdgpu: use scheduler depenencies for CS

Can you test if this solves the freezes: diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 919bbea2e3ac..4e684c2afc70 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -1506,7 +1509,8

Re: [6.2][regression] looks like commit aab9cf7b6954136f4339136a1a7fc0602a2c4d8b leads to use-after-free and random computer hangs

Hi, this is your Linux kernel regression tracker. On 18.12.22 14:28, Mikhail Gavrilov wrote: > > The kernel 6.2 preparation cycle has begun. > And after the kernel was updated on my Fedora Rawhide I started > receiving use-after-free errors with complete computer hangs. > At least a good reproduce

[PATCH 10/13] drm/amdgpu: use scheduler depenencies for CS

Can you test if this solves the freezes: diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 919bbea2e3ac..4e684c2afc70 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -1506,7 +1509,8

Re: [PATCH v3 0/3] Adjust ACPI video detection fallback path

On Thu, Dec 15, 2022 at 8:38 PM Rafael J. Wysocki wrote: > > On Thu, Dec 15, 2022 at 8:20 PM Limonciello, Mario > wrote: > > > > [Public] > > > > > -Original Message- > > > From: Limonciello, Mario > > > Sent: Thursday, December 8, 2022 10:42 > > > To: Rafael J . Wysocki ; Deucher, Alexa

[PATCH 2/2] drm/amd: Re-create firmware framebuffer on failure to probe

If the probe sequence fails then the user is stuck with a frozen screen and can only really recover via SSH or by rebooting and applying nomodeset to the kernel command line. This is particularly problematic as newer GPUs are introduced because distributions may take some time to land newer GPU fi

[PATCH 0/2] Recover from failure to probe GPU

One of the first thing that KMS drivers do during initialization is destroy the system firmware framebuffer by means of `drm_aperture_remove_conflicting_pci_framebuffers` This means that if for any reason the GPU failed to probe the user will be stuck with at best a screen frozen at the last thing

[PATCH 1/2] firmware: sysfb: Allow re-creating system framebuffer after init

When GPU kernel drivers have failed to load for any reason the current experience is that the screen is frozen. This is because one of the first things that these drivers do is to call `sysfb_disable`. For end users this is quite jarring and hard to recover from. Allow drivers to request the fra

Re: [PATCH 0/2] Recover from failure to probe GPU

[adding Thomas Zimmermann to CC list] Hello Mario, Interesting case. On 12/22/22 19:30, Mario Limonciello wrote: > One of the first thing that KMS drivers do during initialization is > destroy the system firmware framebuffer by means of > `drm_aperture_remove_conflicting_pci_framebuffers` > The