Is Duplicate Sequence Number an Issue?

Is Duplicate Sequence Number an Issue?

[Bryan Gillespie]

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:

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.

Sorry if I am asking stupid questions, I am definitely a USB novice.

Any insights on how to determine the cause of this breakage would be
appreciated.

Bryan
-- 
Bryan Gillespie
(801) 664-7527

Re: Is Duplicate Sequence Number an Issue?

[Greg KH]

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