Date: Thu, 25 Mar 2010 21:57:22 -0300 (BRT) From: "Nenhum_de_Nos" <matheus@eternamente.info> To: pyunyh@gmail.com Cc: freebsd-usb@freebsd.org Subject: Re: 10Mbps+ throughput usb based ethernet recommendation Message-ID: <e15b32df866e9001a9f0971b2393bce2.squirrel@cygnus.homeunix.com> In-Reply-To: <20100326003150.GI1278@michelle.cdnetworks.com> References: <a00e68df4a889b419630d96f9f4cb11a.squirrel@lamneth> <5f0d2fca99441437799bc5d7f55d6ea9.squirrel@lamneth> <20100324010107.GM1278@michelle.cdnetworks.com> <3e164e2fc77415a67bd7d22e9c51168b.squirrel@cygnus.homeunix.com> <20100324214230.GT1278@michelle.cdnetworks.com> <20100324215827.GU1278@michelle.cdnetworks.com> <20100324231833.GX1278@michelle.cdnetworks.com> <35a626b67a1556071f4c76498214581d.squirrel@cygnus.homeunix.com> <20100325173556.GA1278@michelle.cdnetworks.com> <b5b7224dd079150dcb9c932ef6603e08.squirrel@cygnus.homeunix.com> <20100326003150.GI1278@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, March 25, 2010 21:31, Pyun YongHyeon wrote: > On Thu, Mar 25, 2010 at 04:42:19PM -0300, Nenhum_de_Nos wrote: >> >> On Thu, March 25, 2010 14:35, Pyun YongHyeon wrote: >> > On Thu, Mar 25, 2010 at 02:22:32PM -0300, Nenhum_de_Nos wrote: >> >> >> >> On Wed, March 24, 2010 20:18, Pyun YongHyeon wrote: >> >> > On Wed, Mar 24, 2010 at 02:58:27PM -0700, Pyun YongHyeon wrote: >> >> >> On Wed, Mar 24, 2010 at 02:42:30PM -0700, Pyun YongHyeon wrote: >> >> >> > On Wed, Mar 24, 2010 at 06:16:21PM -0300, Nenhum_de_Nos wrote: >> >> >> > > >> >> >> > > On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote: >> >> >> > >> >> >> > [...] >> >> >> > >> >> >> > > >> Just adding info, I keep getting these outputs from >> ifconfig: >> >> >> > > >> >> >> >> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> >> metric >> >> 0 >> >> >> mtu >> >> >> > > >> 1500 >> >> >> > > >> ether 00:11:50:e7:39:e9 >> >> >> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast >> 192.168.1.255 >> >> >> > > >> media: Ethernet autoselect (1000baseT <full-duplex>) >> >> >> > > >> status: active >> >> >> > > >> and: >> >> >> > > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> >> metric >> >> 0 >> >> >> mtu >> >> >> > > >> 1500 >> >> >> > > >> ether 00:11:50:e7:39:e9 >> >> >> > > >> inet 192.168.1.1 netmask 0xffffff00 broadcast >> 192.168.1.255 >> >> >> > > >> media: Ethernet autoselect (100baseTX >> >> <full-duplex,hw-loopback>) >> >> >> > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >> > > >> status: active >> >> >> > > >> >> >> >> > > >> and this keeps repeating over and over. iperf and on the >> other >> >> >> end an >> >> >> > > > >> >> >> > > > Maybe this is real problem. It seems PHY have trouble to >> >> establish >> >> >> > > > link. This is FreeBSD stable/8 right? >> >> >> > > >> >> >> > > yes. on 7.2 is even worse :( >> >> >> > > >> >> >> > > > Would you show me the output of "devinfo -rv| grep phy"? >> >> >> > > >> >> >> > > /usr/home/matheus]$ devinfo -rv| grep phy >> >> >> > > ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 >> at >> >> >> phyno=1 >> >> >> > >> >> >> > axe(4) requires correct resolved speed/link status reported from >> >> >> > PHY driver. Otherwise it will incorrectly reprogram some >> registers >> >> >> > and this can result in unexpected result. >> >> >> > The OUI 0x1e from the above looks odd and I'm not aware of any >> PHY >> >> >> > vendors that reports such OUI. Because FreeBSD does not strictly >> >> >> > follows OUI decoding defined by IEEE it's also possible that >> >> >> > FreeBSD incorrectly showed wrong OUI. What is your USB ethernet >> >> >> > controller model? >> >> >> > >> >> >> >> >> >> Please try this patch and let me know the output on your console. >> >> >> It will show you "XXX ID1 = 0xYYYY, ID2 = 0xZZZZ". >> >> >> >> >> > >> >> > Use this patch instead of previous one. >> >> >> >> I applied the patch, and recompiled just the module. no good, then >> mii >> >> module also recompiled. this time I can ping from inside the >> >> freebsd-current vm (vbox) using bridged networking (notebook ethernet >> >> nfe >> >> adapter) connected to this axe device (this on 8-stable native). >> >> >> >> ping runs, but yet looses packets: >> >> >> > >> > The patch just prints some register information which could be used >> > to track down PHY issues. So it's expected one as the patch has no >> > functional changes. >> > >> >> 64 bytes from 192.168.1.1: icmp_seq=125 ttl=64 time=0.507 ms >> >> load: 0.54 cmd: ping 15245 [select] 125.96r 0.01u 0.00s 0% 1372k >> >> 95/126 packets received (75.4%) 0.450 min / 1.359 avg / 51.108 max >> >> 64 bytes from 192.168.1.1: icmp_seq=126 ttl=64 time=0.499 ms >> >> >> >> but I see no messages on console/dmesg/messages file: >> >> >> >> Mar 25 14:04:40 darkside kernel: ue0: link state changed to DOWN >> >> Mar 25 14:04:40 darkside kernel: ue0: link state changed to UP >> >> Mar 25 14:06:17 darkside kernel: ue0: promiscuous mode enabled >> >> Mar 25 14:06:35 darkside kernel: ue0: promiscuous mode disabled >> >> Mar 25 14:15:59 darkside kernel: ugen1.4: <vendor 0x050d> at usbus1 >> >> (disconnected) >> >> Mar 25 14:15:59 darkside kernel: axe0: at uhub1, port 3, addr 4 >> >> (disconnected) >> >> Mar 25 14:15:59 darkside kernel: ukphy0: detached >> >> Mar 25 14:15:59 darkside kernel: miibus1: detached >> >> Mar 25 14:16:00 darkside kernel: nfe0: link state changed to DOWN >> >> Mar 25 14:16:19 darkside kernel: ugen1.4: <vendor 0x050d> at usbus1 >> >> Mar 25 14:16:19 darkside kernel: axe0: <vendor 0x050d product 0x5055, >> >> rev >> >> 2.00/0.01, addr 4> on usbus1 >> >> Mar 25 14:16:19 darkside kernel: axe0: PHYADDR 0xe0:0x01 >> >> Mar 25 14:16:20 darkside kernel: miibus1: <MII bus> on axe0 >> >> Mar 25 14:16:20 darkside kernel: ukphy0: <Generic IEEE 802.3u media >> >> interface> PHY 1 on miibus1 >> >> Mar 25 14:16:20 darkside kernel: ukphy0: 10baseT, 10baseT-FDX, >> >> 100baseTX, >> >> 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto >> >> Mar 25 14:16:20 darkside kernel: ue0: <USB Ethernet> on axe0 >> >> Mar 25 14:16:20 darkside kernel: ue0: Ethernet address: >> >> 00:11:50:e7:39:e9 >> >> Mar 25 14:16:21 darkside kernel: ue0: link state changed to DOWN >> >> Mar 25 14:16:23 darkside kernel: nfe0: link state changed to UP >> >> Mar 25 14:17:06 darkside kernel: ue0: link state changed to UP >> >> >> >> do I need to recompile kernel ? (I will as soon as I get home anyway) >> >> >> > >> > Yes, mii(4) should be recompiled to get the register information. >> > Let me know ukphy(4) output after rebuilding kernel. >> >> there you are: >> >> miibus1: <MII bus> on axe0 >> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1 >> ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949 > > This value looks garbage. :( >> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX, >> 1000baseT, 1000baseT-FDX, auto > > And this time, ukphy(4) also thinks your PHY supports 1000baseSX. > Of course it's wrong because PHY is copper type. > By chance, are you using Belkin F5D5055 USB controller? I remember > another user also reported similar issue. yes. I have two of them. thanks, matheus > Hans, I guess there is not much thing left to do in PHY driver > because accessing these MII registers return garbage. What could be > done in USB subsystem to get more information to know why > controller returns garbage for accessing MII registers? > -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e15b32df866e9001a9f0971b2393bce2.squirrel>