Hi, On Wed, Jan 27, 2016 at 2:03 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 27 Jan 2016, Doug Anderson wrote: > >> Alan, >> >> On Wed, Jan 27, 2016 at 1:34 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> > On Wed, 27 Jan 2016, Doug Anderson wrote: >> > >> >> This patch should fix ya. >> >> >> >> FIXUP: FROMLIST: usb: dwc2: host: Manage frame nums better in scheduler >> >> https://chromium-review.googlesource.com/324185 >> > >> > Hmmm. That fixed the problem of the polls occuring too frequently, but >> > now I see again intervals that are larger than 256 ms. In the most >> > recent test there are two intervals of 512 ms and one of 2048 ms. >> >> OK, good to know. Ugh. I'll have to see if I can reproduce that. If >> I had to guess, though, I'd say that you're probably running into high >> interrupt latency problems. > > Quite possibly. Would that delay the transfers by a full period or > only by one frame? Yeah, that's the part that doesn't make sense. I would not have expected it to be a multiple. If we missed something then we should have picked something sooner to reschedule. Even if the frame we picked to reschedule wasn't ideal you still should have seen it on the bus. In other words, I'd expect lots of 256 ms with the occasional 257, 258, 259. I wouldn't expect 512. Presumably the 512 means that there was an error somewhere and the packet was dropped. I'm actually tracking down a weird full speed hub bug right now and it's possible that it's a more serious / general problem. It's also possible that we're somehow overflowing a FIFO or a queue. I've seen some overflow errors pop by while debugging recently, and those shouldn't happen unless calculations are off somewhere. >> Those problems would be worse on the >> Raspberry Pi than on my system due to the significantly slower >> processor. >> >> Can you confirm that these problems also were introduced by my series? >> AKA: you never saw > 256 ms polls before my series and now you see >> them? > > No, these problems were also present in the kernel without your > patches. Whew! Still good to root cause, but also nice to know that I didn't introduce this one. ;) Of course, had I introduced it it would probably be easier to fix... -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
