Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs"

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Tue, Sep 01, 2015 at 10:17:59AM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Sep 01, 2015 at 05:39:28PM +0300, Ville Syrj�l� wrote:
> > On Tue, Sep 01, 2015 at 08:59:02AM -0500, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Tue, Sep 01, 2015 at 04:17:00PM +0300, Ville Syrj�l� wrote:
> > > > On Mon, Aug 31, 2015 at 01:50:10PM -0500, Felipe Balbi wrote:
> > > > > Hi,
> > > > > 
> > > > > On Mon, Aug 31, 2015 at 08:25:10PM +0300, Ville Syrj�l� wrote:
> > > > > > On Mon, Aug 31, 2015 at 11:54:13AM -0500, Felipe Balbi wrote:
> > > > > > > On Mon, Aug 31, 2015 at 07:48:28PM +0300, ville.syrjala@linux.intel.com wrote:
> > > > > > > > From: Ville Syrj�l� <ville.syrjala@linux.intel.com>
> > > > > > > > 
> > > > > > > > This reverts commit 8f2c9544aba636134303105ecb164190a39dece4.
> > > > > > > > 
> > > > > > > > As it breaks g_ether on my Baytrail FFRD8 device. Everything starts out
> > > > > > > > fine, but after a bit of data has been transferred it just stops
> > > > > > > > flowing.
> > > > > > > > 
> > > > > > > > Note that I do get a bunch of these "NOHZ: local_softirq_pending 08"
> > > > > > > > when booting the machine, but I'm not really sure if they're related
> > > > > > > > to this problem.
> > > > > > > 
> > > > > > > I have a feeling your problem is elsewhere. We *are* completing one TRB
> > > > > > > at a time. By reverting that commit you're just masking the real problem
> > > > > > > and I'd rather get that one fixed.
> > > > > > > 
> > > > > > > How do you reproduce your issue ?
> > > > > > 
> > > > > > Just boot the system, it gets an IP from dnsmasq on my host, then I ssh
> > > > > > into it and do something to produce a bit of console output, after which
> > > > > > g_ether is dead. Eg. 'dmesg' a few times is enough to kill it.
> > > > > 
> > > > > which kernel version ?
> > > > 
> > > > Anything since the patch went in, so 4.1-rc<something>
> > > > 
> > > > > Running as USB2 or USB3 ?
> > > > 
> > > > speed:480, so USB2 I presume?
> > > > 
> > > > > Have you tried
> > > > > linux-next ?
> > > > 
> > > > Tried it now (next-20150901). Equally bad as the rest.
> > > > 
> > > > > I just did 1000 dmesg iterations over ssh with g_ether and
> > > > > saw no issues.
> > > > > 
> > > > > Can you enable dwc3 tracepoints and try again ? (use some very large
> > > > > trace buffer, something around 2 or 4 MiB should be enough).
> > > > 
> > > > Attached one trace from linux-next, and another one with the revert on
> > > > top.
> > > 
> > > are you sure these come from next ?
> > 
> > Yep.
> > 
> > > It makes zero sense :-) Here's an
> > > odd snippet:
> > > 
> > > |             sshd-1719  [000] d.s3    42.579785: dwc3_ep_queue: ep1in: req ffff880077afa540 length 822/1514 ==> 0
> > > |             sshd-1719  [000] d.s3    42.580075: dwc3_ep_queue: ep1in: req ffff880077afa6c0 length 0/334 ==> -108
> > > |  systemd-network-1618  [003] d.s3    42.754796: dwc3_ep_queue: ep1in: req ffff880077afa780 length 0/120 ==> -108
> > > 
> > > your requests are queued with -ESHUTDOWN!!
> > 
> > Looking at the code the tracepoint is before the request is queued, so
> > maybe there's just stale junk in req->status before it gets overwritten
> > by __dwc3_gadget_ep_queue()?
> 
> right, something touched usb_request.status before and the request has
> been recycled.
> 
> > > more requests are queued and that's it. No further traffic. It just
> > > stopped working. No further IRQs, nothing.
> > > 
> > > mine looks very much different (see attached). I don't have any
> > > -ESHUTDOWNs. How did you load g_ether ? Did you pass any extra options ?
> > 
> > g_ether is builtin, and I just pass g_ether.dev_addr=<mac> via kernel cmdline.
> > 
> > > Which IP version are you running ?
> > 
> > ipv4
> 
> I mean the SNPS IP :-) (it's 2.10a, see below)

It's all Greek to me :)

> 
> > GSBUSCFG0 = 0x00000006
> > GSBUSCFG1 = 0x00000f00
> > GTXTHRCFG = 0x230a0000
> > GRXTHRCFG = 0x22800000
> > GCTL = 0x45802002
> > GEVTEN = 0x00000000
> > GSTS = 0x3e800002
> > GSNPSID = 0x5533210a
> 
> this could be a bug with 2.10a where completion IRQs are missed. Any
> chance you can look for you Errata document and see if any exist ? I'm
> using 2.40a.

Ugh. USB isn't my thing, so I'm definitely not going to start hunting down
any obscure docs.

Cc:ing Mathias and Heikki since it looks like they've touched this beast
before. You guys have any docs and/or clue as to what's happening here?

-- 
Ville Syrj�l�
Intel OTC