On Fri, Nov 06, 2015 at 02:48:00PM +0200, Heikki Krogerus wrote: > On Mon, Oct 12, 2015 at 01:37:40PM -0500, Felipe Balbi wrote: > > > > Hi, > > > > Felipe Balbi <balbi@xxxxxx> writes: > > > On Wed, Sep 02, 2015 at 05:09:39PM +0900, Masakazu Mokuno wrote: > > >> Hi, > > >> > > >> On Mon, 31 Aug 2015 11:54:13 -0500 > > >> Felipe Balbi <balbi@xxxxxx> wrote: > > >> > > >> > On Mon, Aug 31, 2015 at 07:48:28PM +0300, ville.syrjala@xxxxxxxxxxxxxxx wrote: > > >> > > From: Ville Syrj舁・<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. > > >> > > >> If usb_request.no_interrupt is flagged, it seems dwc3 does not set IOC > > >> on the corresponding TRB. Does it break the assumption every TRB > > >> (without SG) will trigger one corresponding EP event? > > >> u_ether is the function module that utilizes 'no_interrupt' flag. > > > > > > XferInProgress should still trigger. Besides, I tested with the exact > > > same setup (different SoC though), just look at the thread. > > > > I found a way to reproduce this on my end. What I was missing was the > > use of request.no_interrupt. We won't get XferInProgress for all TRBs if > > IOC isn't set in all of them. > > > > I'll apply this patch ASAP as it fixes the problem I managed to > > reproduce (ping -s 40000 makes it fail here) > > I can see the commit in your next branch, but shouldn't it go in as a > fix? I guess it should also be tagged with the stable tag. It does have the "Cc: stable@xxxxxxxxxxxxxxx". Sorry about the noise :-). Thanks, -- heikki -- 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