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
next prev parent 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®