Network TX/RX fairness is not honored by USB stack

[Pyun YongHyeon]

On Sun, Oct 03, 2010 at 04:54:23PM -0700, Pyun YongHyeon wrote:
> On Sat, Oct 02, 2010 at 08:41:57AM +0200, Hans Petter Selasky wrote:

[...]

> 
> > USB EHCI uses round robin, so this is either USB device problem or a test-
> > program software failure.
> > 
> 
> I'm pretty sure the benchmark program is not broken, so either
> axe(4) or USB stack could be wrong here. I see three issues from
> the UDP torture test.
>  - Either TX or RX could be starved to death. If you start TX test
>    first, RX would be stuck. If you start RX test first, TX would
>    be stuck.

I had some progress for narrowing down the issue. It seems the
issue happens on some revision of axe(4) controller so I guess the
issue is in axe(4), not USB stack.
I spent a lot of time to reproduce it on several axe(4) variants
and only one axe(4) showed TX stuck condition under certain
conditions. I don't believe the controller is in broken state as
there were a couple axe(4) instability issues reported in ML. I
vaguely thought the issue could be related with USB stack at that
time but my testing indicates it might be caused by axe(4).

Unfortunately all USB ethernet controllers did not implement a
watchdog timeout handler in new USB stack so it was not easy to
detect TX stuck condition(USB stack does not detect this
condition). I guess if axe(4) had watchdog timeout code some users
would have already reported the issue.
Is there any reason not to have watchdog timeout handler in driver?
If it is not, why USB ethernet drivers in new USB stack removed
watchdog handler? I'm not sure resetting controller in ue_tick_task
is allowed or not but trying to recover from TX stuck condition by
stopping and reinitializing controller didn't work in axe(4). I
still have to find a root cause why TX stuck happens on certain
axe(4) controller but I have no clue yet.