10Mbps+ throughput usb based ethernet recommendation

Thu Mar 25 19:42:39 UTC 2010

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
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX,
1000baseT, 1000baseT-FDX, auto
ue0: <USB Ethernet> on axe0
ue0: Ethernet address: xx:xx:xx:xx:xx:xx

let me know if you need anything else :)

thanks,

matheus

-- 
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