From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com ([134.134.136.20]:47793 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751188AbbI1S4I (ORCPT ); Mon, 28 Sep 2015 14:56:08 -0400 Date: Mon, 28 Sep 2015 21:56:04 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: David Cohen Cc: Felipe Balbi , Greg Kroah-Hartman , linux-usb@vger.kernel.org, stable@vger.kernel.org, Mathias Nyman , Heikki Krogerus Subject: Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs" Message-ID: <20150928185604.GS26517@intel.com> References: <1441039708-2504-1-git-send-email-ville.syrjala@linux.intel.com> <20150831165413.GF31101@saruman.tx.rr.com> <20150831172510.GC29811@intel.com> <20150831185010.GH31101@saruman.tx.rr.com> <20150901131700.GF29811@intel.com> <20150901135902.GC4728@saruman.tx.rr.com> <20150901143928.GG29811@intel.com> <20150901151759.GF4728@saruman.tx.rr.com> <20150901153754.GH29811@intel.com> <20150907065606.GA1723@kuha.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150907065606.GA1723@kuha.fi.intel.com> Sender: stable-owner@vger.kernel.org List-ID: 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@linux.intel.com wrote: > > > > > > > > > > From: Ville Syrj�l� > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > 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= 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