10Mbps+ throughput usb based ethernet recommendation

Fri Mar 26 00:57:35 UTC 2010

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