Date: Thu, 25 Mar 2010 17:31:50 -0700 From: Pyun YongHyeon <pyunyh@gmail.com> To: Nenhum_de_Nos <matheus@eternamente.info> Cc: freebsd-usb@freebsd.org Subject: Re: 10Mbps+ throughput usb based ethernet recommendation Message-ID: <20100326003150.GI1278@michelle.cdnetworks.com> In-Reply-To: <b5b7224dd079150dcb9c932ef6603e08.squirrel@cygnus.homeunix.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100326003150.GI1278>