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. _______________________________________________ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"