From: Karol Wachowski <karol.wachowski@linux.intel.com>
To: Daksh Sahni <swizzguy76@gmail.com>
Cc: jacek.lawrynowicz@linux.intel.com, jeff.hugo@oss.qualcomm.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
ogabbay@kernel.org, andrzej.kacprowski@linux.intel.com
Subject: Re: [PATCH] accel/ivpu: Disable recovery work on probe failure
Date: Tue, 10 Nov 2026 09:33:12 +0100 [thread overview]
Message-ID: <f585562b-dbdc-415b-a493-475cf545a092@linux.intel.com> (raw)
In-Reply-To: <20261107174215.15818-1-swizzguy76@gmail.com>
On 07-Nov-26 18:42, Daksh Sahni wrote:
> 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>
Hi Daksh,
Thanks for the report and the thorough analysis, it's correct. An error
IRQ that fires once ivpu_boot() has enabled interrupts can queue
recovery_work during probe, and nothing on the probe error path stops
it.
As Sashiko pointed out, disabling the work on err_ipc_fini comes too
late. By then recovery_work may already have run concurrently with
ivpu_boot(). It can also race with a probe that succeeds, which you saw
yourself in one of your runs.
I'll send a v2 that addresses this along the lines you offered and
Sashiko suggested. recovery_work stays disabled for the whole of probe
and is enabled in ivpu_pm_enable(). A recovery requested during probe
is not lost. If ivpu_boot() fails, probe unwinds with nothing pending.
If probe succeeds, ivpu_pm_enable() runs the deferred recovery and
waits for it before issuing the initial autosuspend request. The NPU is
then reset before first use, and the autosuspend no longer lands while
runtime PM is disabled, which covers your second note too. The patch
will keep your Reported-by.
I'm running it through our internal CI first and will post it once that
passes. When it's out, could you test it on your Meteor Lake kexec
setup and reply with your Tested-by? Once I have it, I'll go ahead
and merge.
Thanks,
Karol
> ---
>
> 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);
prev parent reply other threads:[~2026-11-10 8:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 17:42 Daksh Sahni
2026-11-10 8:33 ` Karol Wachowski [this message]
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=f585562b-dbdc-415b-a493-475cf545a092@linux.intel.com \
--to=karol.wachowski@linux.intel.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=linux-kernel@vger.kernel.org \
--cc=ogabbay@kernel.org \
--cc=swizzguy76@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®