From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from devils.ext.ti.com ([198.47.26.153]:59627 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752604AbbIAPSD (ORCPT ); Tue, 1 Sep 2015 11:18:03 -0400 Date: Tue, 1 Sep 2015 10:17:59 -0500 From: Felipe Balbi To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= CC: Felipe Balbi , Greg Kroah-Hartman , , Subject: Re: [PATCH] Revert "usb: dwc3: gadget: drop unnecessary loop when cleaning up TRBs" Message-ID: <20150901151759.GF4728@saruman.tx.rr.com> Reply-To: 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iJXiJc/TAIT2rh2r" Content-Disposition: inline In-Reply-To: <20150901143928.GG29811@intel.com> Sender: stable-owner@vger.kernel.org List-ID: --iJXiJc/TAIT2rh2r Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Sep 01, 2015 at 05:39:28PM +0300, Ville Syrj=E4l=E4 wrote: > On Tue, Sep 01, 2015 at 08:59:02AM -0500, Felipe Balbi wrote: > > Hi, > >=20 > > On Tue, Sep 01, 2015 at 04:17:00PM +0300, Ville Syrj=E4l=E4 wrote: > > > On Mon, Aug 31, 2015 at 01:50:10PM -0500, Felipe Balbi wrote: > > > > Hi, > > > >=20 > > > > On Mon, Aug 31, 2015 at 08:25:10PM +0300, Ville Syrj=E4l=E4 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.i= ntel.com wrote: > > > > > > > From: Ville Syrj=E4l=E4 > > > > > > >=20 > > > > > > > This reverts commit 8f2c9544aba636134303105ecb164190a39dece4. > > > > > > >=20 > > > > > > > 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 st= ops > > > > > > > flowing. > > > > > > >=20 > > > > > > > Note that I do get a bunch of these "NOHZ: local_softirq_pend= ing 08" > > > > > > > when booting the machine, but I'm not really sure if they're = related > > > > > > > to this problem. > > > > > >=20 > > > > > > 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 rea= l problem > > > > > > and I'd rather get that one fixed. > > > > > >=20 > > > > > > How do you reproduce your issue ? > > > > >=20 > > > > > 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, afte= r which > > > > > g_ether is dead. Eg. 'dmesg' a few times is enough to kill it. > > > >=20 > > > > which kernel version ? > > >=20 > > > Anything since the patch went in, so 4.1-rc > > >=20 > > > > Running as USB2 or USB3 ? > > >=20 > > > speed:480, so USB2 I presume? > > >=20 > > > > Have you tried > > > > linux-next ? > > >=20 > > > Tried it now (next-20150901). Equally bad as the rest. > > >=20 > > > > I just did 1000 dmesg iterations over ssh with g_ether and > > > > saw no issues. > > > >=20 > > > > Can you enable dwc3 tracepoints and try again ? (use some very large > > > > trace buffer, something around 2 or 4 MiB should be enough). > > >=20 > > > Attached one trace from linux-next, and another one with the revert on > > > top. > >=20 > > are you sure these come from next ? >=20 > Yep. >=20 > > It makes zero sense :-) Here's an > > odd snippet: > >=20 > > | sshd-1719 [000] d.s3 42.579785: dwc3_ep_queue: ep1in:= req ffff880077afa540 length 822/1514 =3D=3D> 0 > > | sshd-1719 [000] d.s3 42.580075: dwc3_ep_queue: ep1in:= req ffff880077afa6c0 length 0/334 =3D=3D> -108 > > | systemd-network-1618 [003] d.s3 42.754796: dwc3_ep_queue: ep1in:= req ffff880077afa780 length 0/120 =3D=3D> -108 > >=20 > > your requests are queued with -ESHUTDOWN!! >=20 > 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. > >=20 > > 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 ? >=20 > g_ether is builtin, and I just pass g_ether.dev_addr=3D via kernel c= mdline. >=20 > > Which IP version are you running ? >=20 > ipv4 I mean the SNPS IP :-) (it's 2.10a, see below) > GSBUSCFG0 =3D 0x00000006 > GSBUSCFG1 =3D 0x00000f00 > GTXTHRCFG =3D 0x230a0000 > GRXTHRCFG =3D 0x22800000 > GCTL =3D 0x45802002 > GEVTEN =3D 0x00000000 > GSTS =3D 0x3e800002 > GSNPSID =3D 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. --=20 balbi --iJXiJc/TAIT2rh2r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV5cGnAAoJEIaOsuA1yqREh9kP/2FItnsDu+hxUoshVL+dsn0D /QBBKEf7rjnLrr88dYTKf1jvNJd25sw4MScLe2gw/fcCODWrwKXxJvLA+3GNVnHD QTrejLILn8CCinhOqCXl7jICiY6Ed6VR8FH+yD5SRa5F11fbubgCaq3YuThYPmLY XjCbTGlLybLQWfOfpyRrunzBwqUMB0m4H4SmgtfGfbFOCcySFSxEvbvHv5UbjjVE uo2U/RrUtuOucCm7+gh/eV7NOIL0kD01SmN3Enbf6GMxOjTFOx8xJGaiKOiLfV3B DexUZaEQlZchTGBKpatWroEL/3tyMcvfwRea2e4TBZiquGrCwscz05qMhgUATA2i grlS+KXB55rRLeqVycZX5tdJq3EBtTdKRU5aEJ2cX3UbIkKf1Jksp63oyPIJ8mrR 49yjTgkdwq04vxD0sXrHtp2G2Ko5AlFQQFQz4LYxhDElwFf2em2QMNS9WtbZ4cuN zCseYrEtRCJJbJWaaD4Zw9+shxFnub6lxFWnxNobVuSpWP6gDv4CMe3absAtluUf sRq/Z8S9NOr/6ztnIb89/0tPJBOjmH5EV+DSMqdTKJR1YCX/mkhQL8qP+tUHGugv M9BAITvsY36Fdm4UQ5SLaQmf1To5mSiDfmn72QrK/TIhX7VdyCSTnd+ClOHjKOUl rux4pcuP+7zTh3yi0CJt =K8OU -----END PGP SIGNATURE----- --iJXiJc/TAIT2rh2r--