From: Greg KH <gregkh@linuxfoundation.org>
To: Bryan Gillespie <rpgillespie6@gmail.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: Is Duplicate Sequence Number an Issue?
Date: Fri, 3 Jan 2020 12:29:43 +0100 [thread overview]
Message-ID: <20200103112943.GA1051129@kroah.com> (raw)
In-Reply-To: <CAPVsg6LXr-fsz=FG8BDMqOPd73vcgageTk++Bt+fEP4-6DVT6A@mail.gmail.com>
On Tue, Dec 17, 2019 at 11:33:55AM -0500, Bryan Gillespie wrote:
> Hello,
>
> I am trying to debug a USB 3.0 issue under linux 4.4/4.14 where device
> endpoints become unresponsive when sending small packet iperf traffic
> through them. I have a protocol analyzer (Beagle 5000), and I see the
> following at the moment of breakage:
Does 5.4 also show this issue?
> https://i.stack.imgur.com/CrCV7.png
>
> If I expand the packets, I notice that the last good transaction looks
> like this:
>
> https://i.stack.imgur.com/sWxne.png
>
> And the first bad transaction looks like this:
>
> https://i.stack.imgur.com/l85xJ.png
>
> This looks like only a partial transaction? The only thing that stuck
> out to me was that the two data transactions have the exact same
> Sequence Number (SeqNum), which seems like it might be out of spec
> with USB 3.0 (I read that you can only have duplicate sequence numbers
> if it is a retransmission, and it looks like it isn't)? Is xhci under
> linux setting these sequence numbers or is that at the hardware level?
> This issue seems to bubble up the linux usb stack as -EPROTO which has
> no information.
The hardware handles the sequence number, so you might want to make sure
you are using up-to-date silicon.
thanks,
greg k-h
prev parent reply other threads:[~2020-01-03 11:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-17 16:33 Is Duplicate Sequence Number an Issue? Bryan Gillespie
2020-01-03 11:29 ` Greg KH [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=20200103112943.GA1051129@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=rpgillespie6@gmail.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;
as well as URLs for NNTP newsgroup(s).