From: Shawn Guo <shawnguo2@yeah.net>
To: Xu Yang <xu.yang_2@nxp.com>
Cc: Peter Chen <peter.chen@kernel.org>,
Shawn Guo <shawnguo@kernel.org>,
imx@lists.linux.dev, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: i.MX kernel hangup caused by chipidea USB gadget driver
Date: Tue, 10 Jun 2025 17:50:19 +0800 [thread overview]
Message-ID: <aEf/2+3MU5ED2sxE@dragon> (raw)
In-Reply-To: <c56pgxmfscg6tpqxjayu4mvxc2g5kgmfitpvp36lxulpq4jxmg@ces5l7ofab6s>
On Mon, Jun 09, 2025 at 07:53:22PM +0800, Xu Yang wrote:
<snip>
> During the scp process, the usb host won't put usb device to suspend state.
> In current design, then the ether driver doesn't know the system has
> suspended after echo mem. The root cause is that ether driver is still tring
> to queue usb request after usb controller has suspended where usb clock is off,
> then the system hang.
>
> With the above changes, I think the ether driver will fail to eth_start_xmit()
> at an ealier stage, so the issue can't be triggered.
>
> I think the ether driver needs call gether_suspend() accordingly, to do this,
> the controller driver need explicitly call suspend() function when it's going
> to be suspended. Could you check whether below patch fix the issue?
Thanks for the patch, Xu! It does fix the hangup but seems to be less
reliable than my/Peter's change (disconnecting gadget), per my testing
on a custom i.MX8MM board. With your change, host/PC doesn't disconnect
gadget when the board suspends. After a few suspend cycles, Ethernet
gadget stops working and the following workqueue lockup is seen. There
seems to some be other bugs?
[ 223.047990] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 223.054097] rcu: 1-...0: (7 ticks this GP) idle=bb7c/1/0x4000000000000000 softirq=5368/5370 fqs=2431
[ 223.063318] rcu: (detected by 0, t=5252 jiffies, g=4705, q=2400 ncpus=4)
[ 223.070105] Task dump for CPU 1:
[ 223.073330] task:systemd-network state:R running task stack:0 pid:406 ppid:1 flags:0x00000202
[ 223.083248] Call trace:
[ 223.085692] __switch_to+0xc0/0x124
[ 246.747996] BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 43s!
However, your change seems working fine on i.MX8MM EVK. It's probably
due to the fact that host disconnects gadget for some reason when EVK
suspends. This is a different behavior from the custom board above.
We do not really expect this disconnecting, do we?
Shawn
> ---8<--------------------
>
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 8a9b31fd5c89..27a7674ed62c 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -2367,6 +2367,8 @@ static void udc_id_switch_for_host(struct ci_hdrc *ci)
> #ifdef CONFIG_PM_SLEEP
> static void udc_suspend(struct ci_hdrc *ci)
> {
> + ci->driver->suspend(&ci->gadget);
> +
> /*
> * Set OP_ENDPTLISTADDR to be non-zero for
> * checking if controller resume from power lost
> @@ -2389,6 +2391,8 @@ static void udc_resume(struct ci_hdrc *ci, bool power_lost)
> /* Restore value 0 if it was set for power lost check */
> if (hw_read(ci, OP_ENDPTLISTADDR, ~0) == 0xFFFFFFFF)
> hw_write(ci, OP_ENDPTLISTADDR, ~0, 0);
> +
> + ci->driver->resume(&ci->gadget);
> }
> #endif
>
> ---->8------------------
next prev parent reply other threads:[~2025-06-10 9:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 5:31 i.MX kernel hangup caused by chipidea USB gadget driver Shawn Guo
2025-06-09 11:53 ` Xu Yang
2025-06-09 13:54 ` Alan Stern
2025-06-10 10:08 ` Shawn Guo
2025-06-10 11:27 ` Xu Yang
2025-06-09 14:17 ` John Ernberg
2025-06-10 2:12 ` Peter Chen (CIX)
2025-06-10 10:17 ` Shawn Guo
2025-06-10 11:33 ` Xu Yang
2025-06-10 3:04 ` Shawn Guo
2025-06-10 15:03 ` John Ernberg
2025-06-10 11:30 ` Xu Yang
2025-06-10 15:05 ` John Ernberg
2025-06-12 13:23 ` John Ernberg
2025-06-13 3:13 ` Xu Yang
2025-06-10 9:50 ` Shawn Guo [this message]
2025-06-10 11:54 ` Xu Yang
2025-06-11 2:59 ` Shawn Guo
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=aEf/2+3MU5ED2sxE@dragon \
--to=shawnguo2@yeah.net \
--cc=imx@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=peter.chen@kernel.org \
--cc=shawnguo@kernel.org \
--cc=xu.yang_2@nxp.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 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.