It seems 10 secs timeout is too long in general case. A core would wait for
10 secs without doing other task and it can be happended on every device.
It's better to reduce timeout for general case and use new quirk if needed.
Signed-off-by: Daehwan Jung <[email protected]>
---
drivers/usb/host/xhci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 9248ce8..0a1b6be 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -196,7 +196,7 @@ int xhci_reset(struct xhci_hcd *xhci)
udelay(1000);
ret = xhci_handshake(&xhci->op_regs->command,
- CMD_RESET, 0, 10 * 1000 * 1000);
+ CMD_RESET, 0, 1 * 1000 * 1000);
if (ret)
return ret;
@@ -210,7 +210,7 @@ int xhci_reset(struct xhci_hcd *xhci)
* than status until the "Controller Not Ready" flag is cleared.
*/
ret = xhci_handshake(&xhci->op_regs->status,
- STS_CNR, 0, 10 * 1000 * 1000);
+ STS_CNR, 0, 1 * 1000 * 1000);
xhci->usb2_rhub.bus_state.port_c_suspend = 0;
xhci->usb2_rhub.bus_state.suspended_ports = 0;
--
2.7.4
On Tue, Jun 22, 2021 at 08:24:56PM +0900, Daehwan Jung wrote:
> It seems 10 secs timeout is too long in general case. A core would wait for
> 10 secs without doing other task and it can be happended on every device.
Only if the handshake does not come back sooner, right?
What is causing your device to timeout here?
> It's better to reduce timeout for general case and use new quirk if needed.
What new quirk?
And why 1 second, where did that number come from?
>
> Signed-off-by: Daehwan Jung <[email protected]>
> ---
> drivers/usb/host/xhci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 9248ce8..0a1b6be 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -196,7 +196,7 @@ int xhci_reset(struct xhci_hcd *xhci)
> udelay(1000);
>
> ret = xhci_handshake(&xhci->op_regs->command,
> - CMD_RESET, 0, 10 * 1000 * 1000);
> + CMD_RESET, 0, 1 * 1000 * 1000);
> if (ret)
> return ret;
>
> @@ -210,7 +210,7 @@ int xhci_reset(struct xhci_hcd *xhci)
> * than status until the "Controller Not Ready" flag is cleared.
> */
> ret = xhci_handshake(&xhci->op_regs->status,
> - STS_CNR, 0, 10 * 1000 * 1000);
> + STS_CNR, 0, 1 * 1000 * 1000);
With this change, what "goes faster"? What is currently causing
problems with your host controller that this timeout value actually
matters? Why is it failing?
thanks,
greg k-h
On Mon, Jun 28, 2021 at 11:25:48AM +0900, Jung Daehwan wrote:
> On Tue, Jun 22, 2021 at 09:56:20PM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Jun 22, 2021 at 08:24:56PM +0900, Daehwan Jung wrote:
> > > It seems 10 secs timeout is too long in general case. A core would wait for
> > > 10 secs without doing other task and it can be happended on every device.
> >
> > Only if the handshake does not come back sooner, right?
>
> Yes, right.
>
> > What is causing your device to timeout here?
>
> Host Controller doesn't respond handshake. I don't know why and I ask HW team
> to debug it.
Please work to fix your hardware, that feels like the root of the
problem here. If you require the timeout for xhci_reset() to happen,
then how do you know that the hardware really did reset properly in the
reduced amount of time you just provided?
thanks,
greg k-h
On 28.6.2021 9.55, Jung Daehwan wrote:
> On Mon, Jun 28, 2021 at 08:53:02AM +0200, Greg Kroah-Hartman wrote:
>> On Mon, Jun 28, 2021 at 11:25:48AM +0900, Jung Daehwan wrote:
>>> On Tue, Jun 22, 2021 at 09:56:20PM +0200, Greg Kroah-Hartman wrote:
>>>> On Tue, Jun 22, 2021 at 08:24:56PM +0900, Daehwan Jung wrote:
>>>>> It seems 10 secs timeout is too long in general case. A core would wait for
>>>>> 10 secs without doing other task and it can be happended on every device.
>>>>
>>>> Only if the handshake does not come back sooner, right?
>>>
>>> Yes, right.
>>>
>>>> What is causing your device to timeout here?
>>>
>>> Host Controller doesn't respond handshake. I don't know why and I ask HW team
>>> to debug it.
>>
>> Please work to fix your hardware, that feels like the root of the
>> problem here. If you require the timeout for xhci_reset() to happen,
>> then how do you know that the hardware really did reset properly in the
>> reduced amount of time you just provided?
>>
>
> I continue fixing this issue with hardware engineer, but currently just
> host controller can crash whole system and that's why I want to fix it.
> How about adding some error logs in this situation for recognizing this issue?
> We can add error log in xhci_stop as xhci_reset can returns error like below.
>
> static void xhci_stop(struct usb_hcd *hcd)
> {
> u32 temp;
> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> + int ret;
>
> mutex_lock(&xhci->mutex);
>
> @@ -733,6 +734,9 @@ static void xhci_stop(struct usb_hcd *hcd)
> xhci->cmd_ring_state = CMD_RING_STATE_STOPPED;
> xhci_halt(xhci);
> xhci_reset(xhci);
> + if (ret)
> + xhci_err(xhci, "%s: Error while reset xhci Host controller - ret = %d\n"
> + , __func__, ret);
> spin_unlock_irq(&xhci->lock);
>
We can check the xhci_reset() return value here and print a message, makes sense.
The original reason for the 10 second timeout was because a host actually took 9 seconds:
commit 22ceac191211cf6688b1bf6ecd93c8b6bf80ed9b
xhci: Increase reset timeout for Renesas 720201 host.
The NEC/Renesas 720201 xHCI host controller does not complete its reset
within 250 milliseconds. In fact, it takes about 9 seconds to reset the
host controller, and 1 second for the host to be ready for doorbell
rings. Extend the reset and CNR polling timeout to 10 seconds each.
-Mathias
Sorry for the spam. I have added an incorrect email address in my previous
email.
On Fri, Feb 11, 2022 at 12:16:30PM +0530, Pavan Kondeti wrote:
> On Mon, Jun 28, 2021 at 10:49:00AM +0300, Mathias Nyman wrote:
> > On 28.6.2021 9.55, Jung Daehwan wrote:
> > > On Mon, Jun 28, 2021 at 08:53:02AM +0200, Greg Kroah-Hartman wrote:
> > >> On Mon, Jun 28, 2021 at 11:25:48AM +0900, Jung Daehwan wrote:
> > >>> On Tue, Jun 22, 2021 at 09:56:20PM +0200, Greg Kroah-Hartman wrote:
> > >>>> On Tue, Jun 22, 2021 at 08:24:56PM +0900, Daehwan Jung wrote:
> > >>>>> It seems 10 secs timeout is too long in general case. A core would wait for
> > >>>>> 10 secs without doing other task and it can be happended on every device.
> > >>>>
> > >>>> Only if the handshake does not come back sooner, right?
> > >>>
> > >>> Yes, right.
> > >>>
> > >>>> What is causing your device to timeout here?
> > >>>
> > >>> Host Controller doesn't respond handshake. I don't know why and I ask HW team
> > >>> to debug it.
> > >>
> > >> Please work to fix your hardware, that feels like the root of the
> > >> problem here. If you require the timeout for xhci_reset() to happen,
> > >> then how do you know that the hardware really did reset properly in the
> > >> reduced amount of time you just provided?
> > >>
> > >
> > > I continue fixing this issue with hardware engineer, but currently just
> > > host controller can crash whole system and that's why I want to fix it.
> > > How about adding some error logs in this situation for recognizing this issue?
> > > We can add error log in xhci_stop as xhci_reset can returns error like below.
> > >
> > > static void xhci_stop(struct usb_hcd *hcd)
> > > {
> > > u32 temp;
> > > struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> > > + int ret;
> > >
> > > mutex_lock(&xhci->mutex);
> > >
> > > @@ -733,6 +734,9 @@ static void xhci_stop(struct usb_hcd *hcd)
> > > xhci->cmd_ring_state = CMD_RING_STATE_STOPPED;
> > > xhci_halt(xhci);
> > > xhci_reset(xhci);
> > > + if (ret)
> > > + xhci_err(xhci, "%s: Error while reset xhci Host controller - ret = %d\n"
> > > + , __func__, ret);
> > > spin_unlock_irq(&xhci->lock);
> > >
> >
> > We can check the xhci_reset() return value here and print a message, makes sense.
> >
> > The original reason for the 10 second timeout was because a host actually took 9 seconds:
> >
> > commit 22ceac191211cf6688b1bf6ecd93c8b6bf80ed9b
> >
> > xhci: Increase reset timeout for Renesas 720201 host.
> >
> > The NEC/Renesas 720201 xHCI host controller does not complete its reset
> > within 250 milliseconds. In fact, it takes about 9 seconds to reset the
> > host controller, and 1 second for the host to be ready for doorbell
> > rings. Extend the reset and CNR polling timeout to 10 seconds each.
> >
> Agreed.
>
> We also run into the similar issue (very very rarely reproduced) on
> our platforms like SM8450. The issue happens when host mode is de-activated
> (type-c cable disconnected). Since xhci_reset() is called with interrupts
> disabled, a timeout of 10 seconds is fatal to the system.
>
> Thanks,
> Pavan
On Mon, Jun 28, 2021 at 10:49:00AM +0300, Mathias Nyman wrote:
> On 28.6.2021 9.55, Jung Daehwan wrote:
> > On Mon, Jun 28, 2021 at 08:53:02AM +0200, Greg Kroah-Hartman wrote:
> >> On Mon, Jun 28, 2021 at 11:25:48AM +0900, Jung Daehwan wrote:
> >>> On Tue, Jun 22, 2021 at 09:56:20PM +0200, Greg Kroah-Hartman wrote:
> >>>> On Tue, Jun 22, 2021 at 08:24:56PM +0900, Daehwan Jung wrote:
> >>>>> It seems 10 secs timeout is too long in general case. A core would wait for
> >>>>> 10 secs without doing other task and it can be happended on every device.
> >>>>
> >>>> Only if the handshake does not come back sooner, right?
> >>>
> >>> Yes, right.
> >>>
> >>>> What is causing your device to timeout here?
> >>>
> >>> Host Controller doesn't respond handshake. I don't know why and I ask HW team
> >>> to debug it.
> >>
> >> Please work to fix your hardware, that feels like the root of the
> >> problem here. If you require the timeout for xhci_reset() to happen,
> >> then how do you know that the hardware really did reset properly in the
> >> reduced amount of time you just provided?
> >>
> >
> > I continue fixing this issue with hardware engineer, but currently just
> > host controller can crash whole system and that's why I want to fix it.
> > How about adding some error logs in this situation for recognizing this issue?
> > We can add error log in xhci_stop as xhci_reset can returns error like below.
> >
> > static void xhci_stop(struct usb_hcd *hcd)
> > {
> > u32 temp;
> > struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> > + int ret;
> >
> > mutex_lock(&xhci->mutex);
> >
> > @@ -733,6 +734,9 @@ static void xhci_stop(struct usb_hcd *hcd)
> > xhci->cmd_ring_state = CMD_RING_STATE_STOPPED;
> > xhci_halt(xhci);
> > xhci_reset(xhci);
> > + if (ret)
> > + xhci_err(xhci, "%s: Error while reset xhci Host controller - ret = %d\n"
> > + , __func__, ret);
> > spin_unlock_irq(&xhci->lock);
> >
>
> We can check the xhci_reset() return value here and print a message, makes sense.
>
> The original reason for the 10 second timeout was because a host actually took 9 seconds:
>
> commit 22ceac191211cf6688b1bf6ecd93c8b6bf80ed9b
>
> xhci: Increase reset timeout for Renesas 720201 host.
>
> The NEC/Renesas 720201 xHCI host controller does not complete its reset
> within 250 milliseconds. In fact, it takes about 9 seconds to reset the
> host controller, and 1 second for the host to be ready for doorbell
> rings. Extend the reset and CNR polling timeout to 10 seconds each.
>
Agreed.
We also run into the similar issue (very very rarely reproduced) on
our platforms like SM8450. The issue happens when host mode is de-activated
(type-c cable disconnected). Since xhci_reset() is called with interrupts
disabled, a timeout of 10 seconds is fatal to the system.
Thanks,
Pavan
Hi Greg,
On Mon, Feb 14, 2022 at 06:22:16AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 14, 2022 at 09:38:38AM +0530, Pavan Kondeti wrote:
> > Hi Greg,
> >
> > On Fri, Feb 11, 2022 at 01:13:31PM +0530, Pavan Kondeti wrote:
> > > Sorry for the spam. I have added an incorrect email address in my previous
> > > email.
> > >
> > > On Fri, Feb 11, 2022 at 12:16:30PM +0530, Pavan Kondeti wrote:
> > > > On Mon, Jun 28, 2021 at 10:49:00AM +0300, Mathias Nyman wrote:
> > > > > On 28.6.2021 9.55, Jung Daehwan wrote:
> > > > > > On Mon, Jun 28, 2021 at 08:53:02AM +0200, Greg Kroah-Hartman wrote:
> > > > > >> On Mon, Jun 28, 2021 at 11:25:48AM +0900, Jung Daehwan wrote:
> > > > > >>> On Tue, Jun 22, 2021 at 09:56:20PM +0200, Greg Kroah-Hartman wrote:
> > > > > >>>> On Tue, Jun 22, 2021 at 08:24:56PM +0900, Daehwan Jung wrote:
>
> <snip>
>
> > Can you please consider including this change? Let us know if you want this
> > patch to be resent again with error message and Fixes tag included.
>
> You are responding to an email thread from 6 months ago, without any
> change in it at all, so I have no idea what you are referring to here,
> sorry.
>
> Please resend any patch you wish to have reviewed, as obviously it is no
> longer in our queue and might not even be relevant anymore (you have
> tested 5.17-rc4, right?)
Thanks Greg for the reply. We will test the patch on the latest tree and
resend it.
Thanks,
Pavan
Hi Greg,
On Fri, Feb 11, 2022 at 01:13:31PM +0530, Pavan Kondeti wrote:
> Sorry for the spam. I have added an incorrect email address in my previous
> email.
>
> On Fri, Feb 11, 2022 at 12:16:30PM +0530, Pavan Kondeti wrote:
> > On Mon, Jun 28, 2021 at 10:49:00AM +0300, Mathias Nyman wrote:
> > > On 28.6.2021 9.55, Jung Daehwan wrote:
> > > > On Mon, Jun 28, 2021 at 08:53:02AM +0200, Greg Kroah-Hartman wrote:
> > > >> On Mon, Jun 28, 2021 at 11:25:48AM +0900, Jung Daehwan wrote:
> > > >>> On Tue, Jun 22, 2021 at 09:56:20PM +0200, Greg Kroah-Hartman wrote:
> > > >>>> On Tue, Jun 22, 2021 at 08:24:56PM +0900, Daehwan Jung wrote:
> > > >>>>> It seems 10 secs timeout is too long in general case. A core would wait for
> > > >>>>> 10 secs without doing other task and it can be happended on every device.
> > > >>>>
> > > >>>> Only if the handshake does not come back sooner, right?
> > > >>>
> > > >>> Yes, right.
> > > >>>
> > > >>>> What is causing your device to timeout here?
> > > >>>
> > > >>> Host Controller doesn't respond handshake. I don't know why and I ask HW team
> > > >>> to debug it.
> > > >>
> > > >> Please work to fix your hardware, that feels like the root of the
> > > >> problem here. If you require the timeout for xhci_reset() to happen,
> > > >> then how do you know that the hardware really did reset properly in the
> > > >> reduced amount of time you just provided?
> > > >>
> > > >
> > > > I continue fixing this issue with hardware engineer, but currently just
> > > > host controller can crash whole system and that's why I want to fix it.
> > > > How about adding some error logs in this situation for recognizing this issue?
> > > > We can add error log in xhci_stop as xhci_reset can returns error like below.
> > > >
> > > > static void xhci_stop(struct usb_hcd *hcd)
> > > > {
> > > > u32 temp;
> > > > struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> > > > + int ret;
> > > >
> > > > mutex_lock(&xhci->mutex);
> > > >
> > > > @@ -733,6 +734,9 @@ static void xhci_stop(struct usb_hcd *hcd)
> > > > xhci->cmd_ring_state = CMD_RING_STATE_STOPPED;
> > > > xhci_halt(xhci);
> > > > xhci_reset(xhci);
> > > > + if (ret)
> > > > + xhci_err(xhci, "%s: Error while reset xhci Host controller - ret = %d\n"
> > > > + , __func__, ret);
> > > > spin_unlock_irq(&xhci->lock);
> > > >
> > >
> > > We can check the xhci_reset() return value here and print a message, makes sense.
> > >
> > > The original reason for the 10 second timeout was because a host actually took 9 seconds:
> > >
> > > commit 22ceac191211cf6688b1bf6ecd93c8b6bf80ed9b
> > >
> > > xhci: Increase reset timeout for Renesas 720201 host.
> > >
> > > The NEC/Renesas 720201 xHCI host controller does not complete its reset
> > > within 250 milliseconds. In fact, it takes about 9 seconds to reset the
> > > host controller, and 1 second for the host to be ready for doorbell
> > > rings. Extend the reset and CNR polling timeout to 10 seconds each.
> > >
> > Agreed.
> >
> > We also run into the similar issue (very very rarely reproduced) on
> > our platforms like SM8450. The issue happens when host mode is de-activated
> > (type-c cable disconnected). Since xhci_reset() is called with interrupts
> > disabled, a timeout of 10 seconds is fatal to the system.
Can you please consider including this change? Let us know if you want this
patch to be resent again with error message and Fixes tag included.
Thanks,
Pavan
On Mon, Feb 14, 2022 at 09:38:38AM +0530, Pavan Kondeti wrote:
> Hi Greg,
>
> On Fri, Feb 11, 2022 at 01:13:31PM +0530, Pavan Kondeti wrote:
> > Sorry for the spam. I have added an incorrect email address in my previous
> > email.
> >
> > On Fri, Feb 11, 2022 at 12:16:30PM +0530, Pavan Kondeti wrote:
> > > On Mon, Jun 28, 2021 at 10:49:00AM +0300, Mathias Nyman wrote:
> > > > On 28.6.2021 9.55, Jung Daehwan wrote:
> > > > > On Mon, Jun 28, 2021 at 08:53:02AM +0200, Greg Kroah-Hartman wrote:
> > > > >> On Mon, Jun 28, 2021 at 11:25:48AM +0900, Jung Daehwan wrote:
> > > > >>> On Tue, Jun 22, 2021 at 09:56:20PM +0200, Greg Kroah-Hartman wrote:
> > > > >>>> On Tue, Jun 22, 2021 at 08:24:56PM +0900, Daehwan Jung wrote:
<snip>
> Can you please consider including this change? Let us know if you want this
> patch to be resent again with error message and Fixes tag included.
You are responding to an email thread from 6 months ago, without any
change in it at all, so I have no idea what you are referring to here,
sorry.
Please resend any patch you wish to have reviewed, as obviously it is no
longer in our queue and might not even be relevant anymore (you have
tested 5.17-rc4, right?)
thanks,
greg k-h