mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Wesley Cheng <quic_wcheng@quicinc.com>,
	Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	Jung Daehwan <dh10.jung@samsung.com>
Cc: Felipe Balbi <balbi@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	"quic_jackp@quicinc.com" <quic_jackp@quicinc.com>
Subject: Re: [PATCH v2 1/2] usb: dwc3: Not set DWC3_EP_END_TRANSFER_PENDING in ep cmd fails
Date: Thu, 17 Feb 2022 23:43:22 +0000	[thread overview]
Message-ID: <e3332511-82d3-2892-ad72-a0c167273174@synopsys.com> (raw)
In-Reply-To: <6a1322c4-9589-f4de-d42c-d38af2e12e82@quicinc.com>

Wesley Cheng wrote:
> Hi Thinh,
> 
> On 2/15/2022 9:14 AM, Thinh Nguyen wrote:
>> Jung Daehwan wrote:
>>> Hi Thinh,
>>>
>>> On Mon, Feb 14, 2022 at 06:44:33PM +0000, Thinh Nguyen wrote:
>>>> Hi,
>>>>
>>>> Daehwan Jung wrote:
>>>>> It always sets DWC3_EP_END_TRANSFER_PENDING in dwc3_stop_active_transfer
>>>>> even if dwc3_send_gadget_ep_cmd fails. It can cause some problems like
>>>>
>>>> How does it fail? Timed out?
>>>
>>> Yes, timed out.
>>>>
>>>>> skipping clear stall commmand or giveback from dequeue. We fix to set it
>>>>> only when ep cmd success. Additionally, We clear DWC3_EP_TRANSFER_STARTED
>>>>> for next trb to start transfer not update transfer.
>>>>
>>>> We shouldn't do this. Things will be out of sync. It may work for 1
>>>> scenario, but it won't work for others.
>>>>
>>>> Please help me understand a few things:
>>>>
>>>> 1) What is the scenario that triggers this? Is it random?
>>>>
>>> ep cmd timeout occurs on dequeue request from user side. End Transfer command
>>> would be sent in dwc3_stop_active transfer.
>>
>> At the high level, what's triggering the request dequeue? Is it from a
>> disconnect, change of interface, or simply function driver protocol that
>> changes it.
>>
>> What application was used to trigger this?
>>
> Sorry for jumping in here, but looks like Daehwan is running into a
> similar issue I am seeing as well.
> 
> At least in my scenario, the dequeue is coming from a function driver
> which exposes a device to userspace.  Once that device is closed, it
> will issue a dequeue on all pending/submitted requests.

Dequeuing request is coming from the function driver, but what causes
the dequeue. For example, the End Transfer command due to a disconnect
may give a different clues than a dequeue from a change of interface.

> 
>>>
>>>> 2) Are there other traffics pending while issuing the End Transfer
>>>> command? If so, what transfer type(s)?
>>>>
>>> I haven't checked it yet. 
>>
>> Can you check?
>>
> For the cases where we've collected a crash log, we can see that during
> the END transfer timeouts there was always a pending EP0 transaction.
> We had reached out to our internal HW folks to get some inputs on what
> could be causing this kind of issue, and we were able to get some
> recommendations from their Synopsis POCs.

It's "Synopsys" :)

> 
> It was mentioned that if there was an active EP0 transfer, an end
> transfer command on a non-control EP can fail w/ timed out.
> 

What controller version are you using? And what version is Jung using?
Do you have the STAR number of the issue. If you're using a different
version than Jung's, then it may not be the same issue.

>>>
>>>> 3) Have you tried increasing the timeout?
>>>>
>>> No, I haven't.
>>
>> Can you try up to 10 seconds (just for experiment)
>>
> I've tried this too, and it did not help.
> 
>>>> BR,
>>>> Thinh
>>>>
>>>
>>> This issue occurs very rarely on customer. I only have restricted
>>> information. That's why I've been trying to reproduce it.
>>
>> How did you test your fix if you can't reproduce it?
>>
>>>
>>> Wesley may have run into same issue and you can see this issue in detail.
>>> https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=9d423b69-fc3fd32e-9d43b026-74fe485fff30-77a099b52659410d&q=1&e=20b4d9f5-2599-4f57-8b6a-7c4ec167d228&u=https*3A*2F*2Flore.kernel.org*2Flinux-usb*2F20220203080017.27339-1-quic_wcheng*40quicinc.com*2F__;JSUlJSUlJQ!!A4F2R9G_pg!JWPzNLoO3BFX_IZCVzmHPtxq6frr_VFbSNNaxSQylunt1Y4EauTOefth2LCIcVEuTx8E$ 
>>>
>>
>> I can take a look, but please provide the tracepoints of the failure if
>> you can reproduce it.
>>
> Let me see if I have any previous traces I can share.  If not, I have a
> pretty reliable repro set up I can collect a trace for you.  For now, I
> will focus on just getting the endxfer timeout seen during ep dequeue.
> As mentioned on my patchset, this can happen during device-initiated
> disconnect as well.
> 

Your patch set is still on my todo list. I haven't reviewed it. There's
some concern looking at it from a first glance, I'll check it out more
thoroughly later.

Can you provide the tracepoints?

Thanks,
Thinh

  reply	other threads:[~2022-02-17 23:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20220214111148epcas2p3fac143c7870c53ecadfb6b093fcf626b@epcas2p3.samsung.com>
2022-02-14 11:08 ` [PATCH v2 0/2] Fix ep command fail issue in dequeue Daehwan Jung
     [not found]   ` <CGME20220214111149epcas2p1a1faeda037991885fd6f2f026fa44ec5@epcas2p1.samsung.com>
2022-02-14 11:08     ` [PATCH v2 1/2] usb: dwc3: Not set DWC3_EP_END_TRANSFER_PENDING in ep cmd fails Daehwan Jung
2022-02-14 11:29       ` Greg Kroah-Hartman
2022-02-15  6:58         ` Jung Daehwan
2022-02-15  7:37           ` Greg Kroah-Hartman
2022-02-15  8:20             ` Jung Daehwan
2022-02-14 18:44       ` Thinh Nguyen
2022-02-15  6:39         ` Jung Daehwan
2022-02-15 17:14           ` Thinh Nguyen
2022-02-17 20:05             ` Wesley Cheng
2022-02-17 23:43               ` Thinh Nguyen [this message]
2022-02-22 18:08                 ` Wesley Cheng
2022-02-23  2:59                   ` Thinh Nguyen
2022-02-24 21:45                     ` Wesley Cheng
2022-02-25  1:26                       ` Thinh Nguyen
2022-02-25  1:31                         ` Wesley Cheng
2022-02-25  1:44                           ` Thinh Nguyen
2022-02-28 22:53                             ` Wesley Cheng
2022-03-01  1:09                               ` Thinh Nguyen
2022-03-01  2:09                                 ` Wesley Cheng
2022-03-01  3:02                                   ` Thinh Nguyen
2022-03-04 21:58                                     ` Wesley Cheng
2022-03-05  0:53                                       ` Thinh Nguyen
2022-03-07 22:57                                         ` Wesley Cheng
2022-03-07 23:51                                           ` Thinh Nguyen
2022-03-08 19:20                                             ` Wesley Cheng
2022-02-18  4:44             ` Jung Daehwan
2022-02-23  2:11               ` Thinh Nguyen
     [not found]   ` <CGME20220214111149epcas2p29b9e39b84d7203572422531beb3c39ed@epcas2p2.samsung.com>
2022-02-14 11:08     ` [PATCH v2 2/2] usb: dwc3: Prevent cleanup cancelled requests at the same time Daehwan Jung
2022-02-14 11:30       ` Greg Kroah-Hartman

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=e3332511-82d3-2892-ad72-a0c167273174@synopsys.com \
    --to=thinh.nguyen@synopsys.com \
    --cc=balbi@kernel.org \
    --cc=dh10.jung@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=quic_jackp@quicinc.com \
    --cc=quic_wcheng@quicinc.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®