From: Johan Hovold <johan@kernel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: mhi@lists.linux.dev, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org,
Loic Poulain <loic.poulain@linaro.org>
Subject: Re: mhi resume failure on reboot with 6.13-rc2
Date: Wed, 18 Dec 2024 14:55:02 +0100 [thread overview]
Message-ID: <Z2LUNo--8YpLO6kD@hovoldconsulting.com> (raw)
In-Reply-To: <20241218123019.py57s4r3takm2fs6@thinkpad>
On Wed, Dec 18, 2024 at 06:00:19PM +0530, Manivannan Sadhasivam wrote:
> On Wed, Dec 18, 2024 at 01:02:39PM +0100, Johan Hovold wrote:
> > On Wed, Dec 18, 2024 at 05:08:30PM +0530, Manivannan Sadhasivam wrote:
> > > On Wed, Dec 18, 2024 at 09:40:45AM +0100, Johan Hovold wrote:
> >
> > > > I've tracked down the hang to a deadlock on the parent device lock.
> > > >
> > > > Driver core takes the parent device lock before calling shutdown(), and
> > > > then mhi_pci_shutdown() waits indefinitely for the recovery thread to
> > > > finish.
> >
> > > Thanks for tracking the deadlock. I think we should use pci_try_reset_function()
> > > instead of pci_reset_function() in mhi_pci_recovery_work().
> > >
> > > If the pci_dev_lock() is already taken, it will return with -EAGAIN and we do
> > > not need to worry in that case since the host is going to be powered off anyway
> > > (and so the device).
> >
> > That may work. But note that I've now also seen this deadlock during
> > suspend (i.e. when the device is not going away). The
> > pci_try_reset_function() should avoid the deadlock here too, but we'll
> > end up in funny state.
>
> Hopefully, recovery_work() started by mhi_pci_runtime_resume() would be able to
> reset the device.
But that's not going to happen as that reset is what is currently
causing the deadlock and which would simply be skipped if you switch to
pci_try_reset_function().
Johan
next prev parent reply other threads:[~2024-12-18 13:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-11 14:17 mhi resume failure on reboot with 6.13-rc2 Johan Hovold
2024-12-11 14:53 ` Manivannan Sadhasivam
2024-12-11 15:03 ` Johan Hovold
2024-12-16 7:40 ` Manivannan Sadhasivam
2024-12-16 7:43 ` Manivannan Sadhasivam
2024-12-16 13:20 ` Johan Hovold
2024-12-16 14:13 ` Manivannan Sadhasivam
2024-12-16 16:25 ` Loic Poulain
2024-12-17 9:57 ` Johan Hovold
2024-12-18 8:48 ` Johan Hovold
2024-12-18 8:40 ` Johan Hovold
2024-12-18 11:38 ` Manivannan Sadhasivam
2024-12-18 12:02 ` Johan Hovold
2024-12-18 12:30 ` Manivannan Sadhasivam
2024-12-18 13:55 ` Johan Hovold [this message]
2024-12-18 14:09 ` Manivannan Sadhasivam
2024-12-18 14:26 ` Johan Hovold
2024-12-18 18:35 ` Manivannan Sadhasivam
2024-12-19 8:36 ` Johan Hovold
2025-01-08 12:49 ` Manivannan Sadhasivam
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=Z2LUNo--8YpLO6kD@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loic.poulain@linaro.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mhi@lists.linux.dev \
/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.