All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Sriharsha Allenki <sallenki@codeaurora.org>,
	gregkh@linuxfoundation.org, linux-usb@vger.kernel.org
Cc: jackp@codeaurora.org, mgautam@codeaurora.org
Subject: Re: [PATCH] usb: dwc3: Do not process request if HWO is set for its TRB
Date: Tue, 10 Dec 2019 13:46:04 +0200	[thread overview]
Message-ID: <878snkl7yb.fsf@gmail.com> (raw)
In-Reply-To: <4c34d724-6a45-dc21-2d10-337f358015ce@codeaurora.org>


Hi,

Sriharsha Allenki <sallenki@codeaurora.org> writes:
>>>> what problem you actually found? Preferrably with tracepoint data
>>>> showing the fault.
>>> Test case here involves f_fs driver in AIO mode and we see ~8 TRBs in
>>> the queue with HWO set and UPDATE_XFER done. In the failure case I see
>>> thatas part of processingthe interrupt generated by the core for the
>>> completion of the first TRB, the driver isgoing ahead and giving
>> we shouldn't get completion interrupt for the first TRB, only the
>> last. Care to share tracepoint data?
>
> We have seen the issue only once and we do not have any tracepoint
> data for it. But with the internal logging we have in our downstream code,
> I see a race between dequeue from the function driver, and the giveback
> as part of the completion (XferInProgress).

Which other changes do you have in your downstream code? Could this
problem be caused by some of the changes in your downstream tree?

> A request (say Request-1) is dequeued before we could notify it's
> completion to the gadget driver. Because of this, as part of handling
> the completion event for the Request-1 we gaveback the next
> request(Request-2) in the queue which is yet to be processed by the
> core leading to the mentioned SMMU fault.

I really need to see tracepoint of this happening. Every list
modification happens with locks held.

> Normally, the core should not process the TRBs once a request
> has been dequeued because of the stop_active_transfer as part of
> dequeue, but I see a timeout when issuing the end transfer command
> during dequeue because of which core is still processing the TRBs
> in the queue.

Ok, so that's the real problem. End Transfer times out. Are you fixing
the wrong thing?

Please, collect trace point data with UPSTREAM kernel. You can't report
a bug on a downstream kernel without reproducing it in the upstream;
otherwise we will be running in circles here.

-- 
balbi

      parent reply	other threads:[~2019-12-10 11:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1574946055-3788-1-git-send-email-sallenki@codeaurora.org>
2019-12-02  7:12 ` [PATCH] usb: dwc3: Do not process request if HWO is set for its TRB Sriharsha Allenki
     [not found] ` <1575270714-29994-1-git-send-email-sallenki@codeaurora.org>
2019-12-02  7:36   ` Felipe Balbi
2019-12-02 10:30     ` Sriharsha Allenki
2019-12-03 12:30       ` Felipe Balbi
2019-12-10  6:50         ` Sriharsha Allenki
     [not found]         ` <4c34d724-6a45-dc21-2d10-337f358015ce@codeaurora.org>
2019-12-10 11:46           ` Felipe Balbi [this message]

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=878snkl7yb.fsf@gmail.com \
    --to=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jackp@codeaurora.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mgautam@codeaurora.org \
    --cc=sallenki@codeaurora.org \
    /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.