All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daksh Sahni <swizzguy76@gmail.com>
To: karol.wachowski@linux.intel.com,
	andrzej.kacprowski@linux.intel.com, ogabbay@kernel.org
Cc: jacek.lawrynowicz@linux.intel.com, jeff.hugo@oss.qualcomm.com,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Daksh Sahni <swizzguy76@gmail.com>
Subject: [PATCH] accel/ivpu: Disable recovery work on probe failure
Date: Sat,  7 Nov 2026 23:12:15 +0530	[thread overview]
Message-ID: <20261107174215.15818-1-swizzguy76@gmail.com> (raw)

If the NPU raises an error interrupt while ivpu_dev_init() boots the
firmware, the Buttress, MMU or WDT IRQ handler calls
ivpu_pm_trigger_recovery(), which queues recovery_work. When ivpu_boot()
then fails, the err_ipc_fini path tears the device down without
disabling recovery_work and probe returns an error. devres unmaps the
register BARs while the work is still queued or running, and the work
faults on the first register access:

  BUG: unable to handle page fault for address: ffffcfc6680200f4
  Workqueue: events_unbound ivpu_pm_recovery_work [intel_vpu]
  RIP: 0010:ivpu_hw_ip_ipc_rx_addr_get+0xc/0xb0 [intel_vpu]
  Call Trace:
   ivpu_wait_for_ready+0x155/0x220 [intel_vpu]
   ivpu_boot+0x9e/0x270 [intel_vpu]
   ivpu_resume+0xa4/0xd0 [intel_vpu]
   ivpu_pm_reset_complete+0x2c/0x90 [intel_vpu]
   ivpu_pm_recovery_work+0xf6/0x140 [intel_vpu]
   process_one_work+0x1da/0x3c0
   worker_thread+0x1af/0x340
   kthread+0xfa/0x130
   ret_from_fork+0x2b9/0x380
   ret_from_fork_asm+0x1a/0x30

The work dies between pm_runtime_disable() in ivpu_pm_reset_begin() and
pm_runtime_enable() in ivpu_pm_reset_complete(), so the PCI device is
also left with runtime PM disabled and never autosuspends after a later
rebind.

Commit 5eaa49741119 ("accel/ivpu: Prevent recovery invocation during
probe and resume") stopped IPC failures during probe from triggering
recovery, but the IRQ handlers still can.

Call ivpu_pm_disable_recovery() at the start of the err_ipc_fini path,
as ivpu_dev_fini() already does, so the work is flushed and cannot be
queued again before the device is torn down.

Reproduced on Meteor Lake (Core Ultra 5 125H, vpu_37xx firmware
20260219) by kexec'ing with the NPU runtime-suspended: probe in the new
kernel gets an ATS_ERR Buttress IRQ during firmware boot. With this
change probe still fails with -ECANCELED, there is no oops, and an FLR
followed by a rebind brings the NPU back.

Fixes: 852be13f3bd3 ("accel/ivpu: Add PM support")
Cc: stable@vger.kernel.org
Signed-off-by: Daksh Sahni <swizzguy76@gmail.com>
---

Notes:
    Tested on v7.4-rc1 (d48723711bae).
    
    Two things this patch does not address:
    
    The trigger is kexec with the NPU runtime-suspended in the old kernel.
    The driver has no .shutdown hook, so the new kernel's probe sees stale
    NPU state and gets ATS_ERR. A cold boot doesn't hit it. Whether that
    wants a shutdown hook or a reset at probe seems like your call.
    
    In one of four runs that hit ATS_ERR, probe succeeded while
    recovery_work was running concurrently. Probe returned 0, but the
    autosuspend request from ivpu_pm_enable() landed while recovery had
    runtime PM disabled, so the NPU stayed active until first use. Not
    allowing IRQ-triggered recovery until ivpu_pm_enable() would cover both
    cases; I can send a v2 that does that if you prefer.

 drivers/accel/ivpu/ivpu_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 247ed6b2ff62..4fcccf78ec5d 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -852,6 +852,7 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
 	return 0;
 
 err_ipc_fini:
+	ivpu_pm_disable_recovery(vdev);
 	ivpu_ipc_fini(vdev);
 err_fw_fini:
 	ivpu_fw_fini(vdev);
-- 
2.53.0


             reply	other threads:[~2026-11-07 17:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-07 17:42 Daksh Sahni [this message]
2026-11-07 18:00 ` [PATCH] accel/ivpu: Disable recovery work on probe failure sashiko-bot
2026-11-10  8:33 ` Karol Wachowski
2026-11-10  8:50 ` [PATCH v2] accel/ivpu: Defer recovery until probe completes Karol Wachowski
2026-11-10  9:13   ` sashiko-bot
2026-11-10 11:41     ` Karol Wachowski

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=20261107174215.15818-1-swizzguy76@gmail.com \
    --to=swizzguy76@gmail.com \
    --cc=andrzej.kacprowski@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jacek.lawrynowicz@linux.intel.com \
    --cc=jeff.hugo@oss.qualcomm.com \
    --cc=karol.wachowski@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ogabbay@kernel.org \
    /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.