[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240327-cuddly-smooth-trogon-59c02d@houat>
Date: Wed, 27 Mar 2024 14:27:29 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: Alex Constantino <dreaming.about.electric.sheep@...il.com>,
1054514@...s.debian.org, airlied@...hat.com, carnil@...ian.org, daniel@...ll.ch,
dri-devel@...ts.freedesktop.org, kraxel@...hat.com, linux-kernel@...r.kernel.org,
spice-devel@...ts.freedesktop.org, timo.lindfors@....fi, tzimmermann@...e.de,
virtualization@...ts.linux-foundation.org, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
Subject: Re: [PATCH 1/1] drm/qxl: fixes qxl_fence_wait
Hi,
On Wed, Mar 20, 2024 at 04:25:48PM +0100, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 08.03.24 02:08, Alex Constantino wrote:
> > Fix OOM scenario by doing multiple notifications to the OOM handler through
> > a busy wait logic.
> > Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> > result in a '[TTM] Buffer eviction failed' exception whenever it reached a
> > timeout.
> >
> > Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
> > Link: https://lore.kernel.org/regressions/fb0fda6a-3750-4e1b-893f-97a3e402b9af@leemhuis.info
> > Reported-by: Timo Lindfors <timo.lindfors@....fi>
> > Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054514
> > Signed-off-by: Alex Constantino <dreaming.about.electric.sheep@...il.com>
> > ---
> > drivers/gpu/drm/qxl/qxl_release.c | 20 ++++++++++++++------
> > 1 file changed, 14 insertions(+), 6 deletions(-)
>
> Hey Dave and Gerd as well as Thomas, Maarten and Maxime (the latter two
> I just added to the CC), it seems to me this regression fix did not
> maybe any progress since it was posted. Did I miss something, is it just
> "we are busy with the merge window", or is there some other a reason?
> Just wondering, I just saw someone on a Fedora IRC channel complaining
> about the regression, that's why I'm asking. Would be really good to
> finally get this resolved...
I've ping'd Gerd last week about it, but he couldn't remember the
details of why that patch was warranted in the first place.
If it works, I'd prefer to revert the original patch that we know used
to work instead of coming up with some less proven logic, which seems to
be quite different to what it used to be.
Alex, could you try reverting 5a838e5d5825c85556011478abde708251cc0776
and letting us know the result?
Thanks!
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)
Powered by blists - more mailing lists