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:

quoted

On Tue, Sep 01, 2015 at 10:17:59AM -0500, Felipe Balbi wrote:

quoted

Hi,

On Tue, Sep 01, 2015 at 05:39:28PM +0300, Ville Syrj�l� wrote:

quoted

On Tue, Sep 01, 2015 at 08:59:02AM -0500, Felipe Balbi wrote:

quoted

Hi,

On Tue, Sep 01, 2015 at 04:17:00PM +0300, Ville Syrj�l� wrote:

quoted

On Mon, Aug 31, 2015 at 01:50:10PM -0500, Felipe Balbi wrote:

quoted

Hi,

On Mon, Aug 31, 2015 at 08:25:10PM +0300, Ville Syrj�l� wrote:

quoted

On Mon, Aug 31, 2015 at 11:54:13AM -0500, Felipe Balbi wrote:

quoted

On Mon, Aug 31, 2015 at 07:48:28PM +0300, ville.syrjala@linux.intel.com wrote:

quoted

From: Ville Syrj�l� <redacted>

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>

quoted

Running as USB2 or USB3 ?

speed:480, so USB2 I presume?

quoted

Have you tried
linux-next ?

Tried it now (next-20150901). Equally bad as the rest.

quoted

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.

quoted

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.

quoted

quoted

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.

quoted

Which IP version are you running ?

ipv4

I mean the SNPS IP :-) (it's 2.10a, see below)

It's all Greek to me :)

quoted

quoted

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