Bug in split transactions on Raspberry Pi

[Doug Anderson]

Hi,

On Wed, Jan 27, 2016 at 2:03 PM, Alan Stern <stern at rowland.harvard.edu> wrote:
> On Wed, 27 Jan 2016, Doug Anderson wrote:
>
>> Alan,
>>
>> On Wed, Jan 27, 2016 at 1:34 PM, Alan Stern <stern at rowland.harvard.edu> 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