On Tuesday 13 April 2010 02:52:55 Pyun YongHyeon wrote:
> 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 <pyu...@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.

Hi,

Try to re-test with 8-stable or 9-current (kernel+kernel modules only). We had 
some EHCI fixes go in for certain chipsets, due to what appears to be hardware 
bugs. So far there has been very few bugs in the EHCI driver. Try to compare 
verbose output, and see that the pnpinfo is identical!

--HPS
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to