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

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 4008 bytes --]

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)

> 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.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]