From owner-freebsd-usb@FreeBSD.ORG Tue Apr 13 06:52:37 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 15F6E106566C for ; Tue, 13 Apr 2010 06:52:37 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.tele2.se [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id 6ACEB8FC08 for ; Tue, 13 Apr 2010 06:52:35 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=8JYm3rmnu3MA:10 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=pGLkceISAAAA:8 a=muwRGhBjV5_1QVj9cCIA:9 a=sn8olJgvphKtClvql0oA:7 a=oueiU2savXaxVnIcocY_p7iFujgA:4 a=wPNLvfGTeEIA:10 a=MSl-tDqOz04A:10 a=cJ7ytZJ4EQYNnmRu:21 a=05bgqzFPmYD7Sl9S:21 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 615007055; Tue, 13 Apr 2010 08:52:33 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org, pyunyh@gmail.com Date: Tue, 13 Apr 2010 08:50:13 +0200 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <20100405011256.GC1225@michelle.cdnetworks.com> <20100413005255.GJ1444@michelle.cdnetworks.com> In-Reply-To: <20100413005255.GJ1444@michelle.cdnetworks.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004130850.13572.hselasky@c2i.net> Cc: Subject: Re: 10Mbps+ throughput usb based ethernet recommendation X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 06:52:37 -0000 On Tuesday 13 April 2010 02:52:55 Pyun YongHyeon wrote: > On Sun, Apr 04, 2010 at 06:12:56PM -0700, Pyun YongHyeon wrote: > > On Sat, Apr 03, 2010 at 09:46:59PM -0300, Nenhum_de_Nos wrote: > > > On Wed, 31 Mar 2010 12:06:31 -0700 > > > > > > Pyun YongHyeon wrote: > > > > On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: > > > > > > > > [...] > > > > > > > > > >> I changed and got this: > > > > > >> > > > > > >> miibus1: on axe0 > > > > > >> ukphy0: PHY 1 on miibus1 > > > > > >> ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 > > > > > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > > > > > > > This is *NOT* bogus value. It's Agere Systems' ET1011 gigabit > > > > > > PHY. FreeBSD has truephy(4) for Agere Systems' PHY but it does > > > > > > not have support code for the model yet. > > > > > > > > > > so I can think that's the issue, right ? > > > > > > > > Probably. But this does not explain sometimes why you get some > > > > bogus value form PHY id registers. > > > > > > > > > >> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > > > > > >> 1000baseT, 1000baseT-FDX, auto > > > > > >> ue0: on axe0 > > > > > >> ue0: Ethernet address: xxxxxxxxxxxxxx > > > > > >> ue0: link state changed to DOWN > > > > > >> > > > > > >> so it didn't now. other thing is that not every time it works: > > > > > > > > > > > > Yeah, that is real issue here. I guess there should be some magic > > > > > > to wakeup the PHY from deep sleep state. I'll see what can be > > > > > > done. > > > > > > > > > > ok, great it was found :) > > > > > > > > > > let me know if I can help in anything :) > > > > > > > > Would you try attached patch and let me know how it goes? > > > > > > axe0: PHYADDR 0xe0:0x01 > > > miibus1: on axe0 > > > ukphy0: PHY 1 on miibus1 > > > ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949 > > > > Due to other issues previous patch didn't have chance to make it > > work. This time, PHY id started to reporting garbage again which > > means all MII register access may return garbage too. Don't know > > this could be related with USB subsystem though. > > > > > ukphy0: 10baseT-FDX > > > ue0: on axe0 > > > ue0: Ethernet address: 00:11:50:e7:39:e9 > > > ue0: link state changed to DOWN > > > > [...] > > > > > and I can't ping the other host :( > > > > > > ue0: flags=8843 metric 0 mtu > > > 1500 options=80000 > > > ether 00:11:50:e7:39:e9 > > > inet 10.2.1.2 netmask 0xffffff00 broadcast 10.2.1.255 > > > media: Ethernet none > > > arroway# ifconfig ue0 > > > ue0: flags=8843 metric 0 mtu > > > 1500 options=80000 > > > ether 00:11:50:e7:39:e9 > > > inet 10.2.1.2 netmask 0xffffff00 broadcast 10.2.1.255 > > > media: Ethernet none (none ) > > > status: active > > > arroway# ifconfig ue0 > > > ue0: flags=8843 metric 0 mtu > > > 1500 options=80000 > > > ether 00:11:50:e7:39:e9 > > > inet 10.2.1.2 netmask 0xffffff00 broadcast 10.2.1.255 > > > media: Ethernet none > > > > > > and it is still crazy media changing. > > > > Because your PHY is not recognized it's expected result. :-( > > Today I got ordered Belkin F5D5055 USB controller. And I believe > this controller is the same one as you have. With the previous patch > it worked as expected on my box. > > axe0: on > usbus7 > axe0: PHYADDR 0xe0:0x01 > miibus0: on axe0 > truephy0: PHY 1 on miibus0 > truephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, > auto ue0: on axe0 > ue0: Ethernet address: 00:22:75:d6:ab:88 > ue0: link state changed to DOWN > ue0: link state changed to UP > > And the performance number for the controller is also similar to > other AX88178 gigabit controllers. So I guess axe(4) has no issue > in handling Belkin F5D5055 USB controller but underlying ehci(4) > could be behaving incorrectly. I believe this part could be > explained/debugged by Hans. > Mine is the following. > > ehci1 pnpinfo vendor=0x8086 device=0x3a6a subvendor=0x1028 > subdevice=0x027f class=0x0c0320 at slot=29 function=7 Interrupt request > lines: > 23 > I/O memory addresses: > 0xff980000-0xff9803ff > usbus7 > uhub7 > axe0 pnpinfo vendor=0x050d product=0x5055 devclass=0xff > devsubclass=0xff sernum="" release=0x0001 intclass=0xff intsubclass=0xff > at port=5 interface=0 miibus0 > truephy0 pnpinfo oui=0xa0bc model=0x1 rev=0x4 at phyno=1 > > Hope this helps. Hi, Try to re-test with 8-stable or 9-current (kernel+kernel modules only). We had some EHCI fixes go in for certain chipsets, due to what appears to be hardware bugs. So far there has been very few bugs in the EHCI driver. Try to compare verbose output, and see that the pnpinfo is identical! --HPS