On Mon, Sep 07, 2015 at 09:56:06AM +0300, Heikki Krogerus wrote: > Hi, > > On Tue, Sep 01, 2015 at 06:37:54PM +0300, Ville Syrjälä wrote: > > 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@xxxxxxxxxxxxxxx wrote: > > > > > > > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > > > > > > > > > > > > > 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? > > I don't, but maybe David knows something. I believe he has worked with > your board in the past. Ping. David any ideas? -- Ville Syrjälä Intel OTC -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html