Hi Greg,
Please do note that there is a revert for this patch that was part of the same pull request. That needs to be picked in too in case you are picking the original patch.
I already got the automated mails from Sasha that both the original commit and revert were already picked into 6.1, 6.6 and 6.12 trees. Are now in a perpetual machinery induced loop where the original commit and revert will be picked in alternating fashion to the stable trees? [1]
Regards, Joonas
[1] Originally, I was under the assumption stable machinery would automatically skip over patches that have later been reverted, but that doesn't seem to be the case?
Quoting gregkh@linuxfoundation.org (2025-06-30 14:39:44)
This is a note to let you know that I've just added the patch titled
drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1
to the 6.1-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...
The filename of the patch is: drm-i915-gem-allow-exec_capture-on-recoverable-contexts-on-dg1.patch and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let stable@vger.kernel.org know about it.
From 25eeba495b2fc16037647c1a51bcdf6fc157af5c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= ville.syrjala@linux.intel.com Date: Mon, 12 May 2025 21:22:15 +0200 Subject: drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
From: Ville Syrjälä ville.syrjala@linux.intel.com
commit 25eeba495b2fc16037647c1a51bcdf6fc157af5c upstream.
The intel-media-driver is currently broken on DG1 because it uses EXEC_CAPTURE with recovarable contexts. Relax the check to allow that.
I've also submitted a fix for the intel-media-driver: https://github.com/intel/media-driver/pull/1920
Cc: stable@vger.kernel.org # v6.0+ Cc: Matthew Auld matthew.auld@intel.com Cc: Thomas Hellström thomas.hellstrom@linux.intel.com Testcase: igt/gem_exec_capture/capture-invisible Fixes: 71b1669ea9bd ("drm/i915/uapi: tweak error capture on recoverable contexts") Reviewed-by: Andi Shyti andi.shyti@linux.intel.com Signed-off-by: Ville Syrjälä ville.syrjala@linux.intel.com Signed-off-by: Andi Shyti andi.shyti@kernel.org Link: https://lore.kernel.org/r/20250411144313.11660-2-ville.syrjala@linux.intel.c... (cherry picked from commit d6e020819612a4a06207af858e0978be4d3e3140) Signed-off-by: Joonas Lahtinen joonas.lahtinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -2001,7 +2001,7 @@ static int eb_capture_stage(struct i915_ continue; if (i915_gem_context_is_recoverable(eb->gem_context) &&
(IS_DGFX(eb->i915) || GRAPHICS_VER_FULL(eb->i915) > IP_VER(12, 0)))
GRAPHICS_VER_FULL(eb->i915) > IP_VER(12, 10)) return -EINVAL;
for_each_batch_create_order(eb, j) {
Patches currently in stable-queue which might be from ville.syrjala@linux.intel.com are
queue-6.1/drm-dp-change-aux-dpcd-probe-address-from-dpcd_rev-to-lane0_1_status.patch queue-6.1/revert-drm-i915-gem-allow-exec_capture-on-recoverabl.patch queue-6.1/drm-i915-gem-allow-exec_capture-on-recoverable-contexts-on-dg1.patch queue-6.1/drm-i915-gem-allow-exec_capture-on-recoverable-conte.patch
On Tue, Jul 01, 2025 at 01:42:05PM +0300, Joonas Lahtinen wrote:
Hi Greg,
Please do note that there is a revert for this patch that was part of the same pull request. That needs to be picked in too in case you are picking the original patch.
I already got the automated mails from Sasha that both the original commit and revert were already picked into 6.1, 6.6 and 6.12 trees. Are now in a perpetual machinery induced loop where the original commit and revert will be picked in alternating fashion to the stable trees? [1]
Yes.
Regards, Joonas
[1] Originally, I was under the assumption stable machinery would automatically skip over patches that have later been reverted, but that doesn't seem to be the case?
Nope, if that were to happen then we would be adding it back over time as we would go "hey, we missed this one!" all the time. Adding the commit and revert is best.
thanks
greg k-h
linux-stable-mirror@lists.linaro.org