From owner-freebsd-usb@FreeBSD.ORG Tue Oct 5 20:56:50 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE0D21065674; Tue, 5 Oct 2010 20:56:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 97B368FC18; Tue, 5 Oct 2010 20:56:50 +0000 (UTC) Received: by pvc21 with SMTP id 21so2180357pvc.13 for ; Tue, 05 Oct 2010 13:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=trBJDX3D/nNOg0Kxcfi2YYW/u3JaFuIk8TJiucYJcKc=; b=a78l9ifz3uuf6u66pH2e/PlRQUei6I43ouBpScpvEOQrUsY29WoRZXKwxbjyN4lNQa KgsYJHja9iB7ZsAy4Dyl2V1zZB1zsviNxYVbmnXFC6kZ93IW/+nkSmbQJZxpwggqZd9d isG2MiIR6wkz8CxbHT+9AInbYCkCeU1bNdMc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=T5Xnp/aMsGSiuhJeDPTMrWcv3wAxccl5Xdf6+4kFfkqBu7yT63lkt2mElQEHeRNjKf 8bgMeWp4chFbzKZ7RE/ifrtCx0KvIOwEGt2kJpxdGz6APiNqDl9K1gZB5CdQ05w3RkKD yOaiXhBTw4YvqCmsNDO8hG0YEHLzEIKW0j000= Received: by 10.114.26.6 with SMTP id 6mr14369370waz.82.1286312210024; Tue, 05 Oct 2010 13:56:50 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id r37sm10064wak.11.2010.10.05.13.56.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 Oct 2010 13:56:48 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 5 Oct 2010 13:55:03 -0700 From: Pyun YongHyeon Date: Tue, 5 Oct 2010 13:55:03 -0700 To: Hans Petter Selasky Message-ID: <20101005205503.GF9920@michelle.cdnetworks.com> References: <20101002001100.GL10521@michelle.cdnetworks.com> <201010020841.57474.hselasky@freebsd.org> <20101003235423.GB1135@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101003235423.GB1135@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-usb@freebsd.org Subject: Re: Network TX/RX fairness is not honored by USB stack X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 20:56:51 -0000 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.