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
next 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.