10Mbps+ throughput usb based ethernet recommendation

[Pyun YongHyeon]

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 <pyunyh at gmail.com> wrote:
> > 
> > > On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote:
> > > 
> > > [...]
> > > 
> > > > >> I changed and got this:
> > > > >>
> > > > >> miibus1: <MII bus> on axe0
> > > > >> ukphy0: <Generic IEEE 802.3u media interface> 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: <USB Ethernet> 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: <MII bus> on axe0
> > ukphy0: <Generic IEEE 802.3u media interface> 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: <USB Ethernet> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> >         options=80000<LINKSTATE>
> >         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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> >         options=80000<LINKSTATE>
> >         ether 00:11:50:e7:39:e9
> >         inet 10.2.1.2 netmask 0xffffff00 broadcast 10.2.1.255
> >         media: Ethernet none (none <hw-loopback>)
> >         status: active
> > arroway# ifconfig ue0
> > ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> >         options=80000<LINKSTATE>
> >         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: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 2> on
usbus7
axe0: PHYADDR 0xe0:0x01
miibus0: <MII bus> on axe0
truephy0: <ET1011 10/100/1000baseT PHY> PHY 1 on miibus0
truephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
ue0: <USB Ethernet> 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.