On Mon, Apr 12, 2010 at 05:52:55PM -0700, 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.
FYI: Patch committed to HEAD(r206563). _______________________________________________ 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"