Re: 10Mbps+ throughput usb based ethernet recommendation
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 wrote: > > > > > > > On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: > > > > > > > > [...] > > > > > > > > > >> I changed and got this: > > > > > >> > > > > > >> miibus1: on axe0 > > > > > >> ukphy0: 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: on axe0 > > > > > >> ue0: Ethernet address: xx > > > > > >> 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: on axe0 > > > ukphy0: 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: 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 metric 0 mtu 1500 > > > options=8 > > > ether 00:11:50:e7:39:e9 > > > inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 > > > media: Ethernet none > > > arroway# ifconfig ue0 > > > ue0: flags=8843 metric 0 mtu 1500 > > > options=8 > > > ether 00:11:50:e7:39:e9 > > > inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 > > > media: Ethernet none (none ) > > > status: active > > > arroway# ifconfig ue0 > > > ue0: flags=8843 metric 0 mtu 1500 > > > options=8 > > > ether 00:11:50:e7:39:e9 > > > inet 10.2.1.2 netmask 0xff00 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: on > usbus7 > axe0: PHYADDR 0xe0:0x01 > miibus0: on axe0 > truephy0: PHY 1 on miibus0 > truephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto > ue0: 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: > 0xff98-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"
Re: 10Mbps+ throughput usb based ethernet recommendation
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 wrote: > > > > On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: > > > > > > > > [...] > > > > > > > > > >> I changed and got this: > > > > > >> > > > > > >> miibus1: on axe0 > > > > > >> ukphy0: 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: on axe0 > > > > > >> ue0: Ethernet address: xx > > > > > >> 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: on axe0 > > > ukphy0: 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: 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 metric 0 mtu > > > 1500 options=8 > > > ether 00:11:50:e7:39:e9 > > > inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 > > > media: Ethernet none > > > arroway# ifconfig ue0 > > > ue0: flags=8843 metric 0 mtu > > > 1500 options=8 > > > ether 00:11:50:e7:39:e9 > > > inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 > > > media: Ethernet none (none ) > > > status: active > > > arroway# ifconfig ue0 > > > ue0: flags=8843 metric 0 mtu > > > 1500 options=8 > > > ether 00:11:50:e7:39:e9 > > > inet 10.2.1.2 netmask 0xff00 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: on > usbus7 > axe0: PHYADDR 0xe0:0x01 > miibus0: on axe0 > truephy0: PHY 1 on miibus0 > truephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, > auto ue0: 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: > 0xff98-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...@freeb
Re: 10Mbps+ throughput usb based ethernet recommendation
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 wrote: > > > > > On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: > > > > > > [...] > > > > > > > >> I changed and got this: > > > > >> > > > > >> miibus1: on axe0 > > > > >> ukphy0: 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: on axe0 > > > > >> ue0: Ethernet address: xx > > > > >> 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: on axe0 > > ukphy0: 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: 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 metric 0 mtu 1500 > > options=8 > > ether 00:11:50:e7:39:e9 > > inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 > > media: Ethernet none > > arroway# ifconfig ue0 > > ue0: flags=8843 metric 0 mtu 1500 > > options=8 > > ether 00:11:50:e7:39:e9 > > inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 > > media: Ethernet none (none ) > > status: active > > arroway# ifconfig ue0 > > ue0: flags=8843 metric 0 mtu 1500 > > options=8 > > ether 00:11:50:e7:39:e9 > > inet 10.2.1.2 netmask 0xff00 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: on usbus7 axe0: PHYADDR 0xe0:0x01 miibus0: on axe0 truephy0: PHY 1 on miibus0 truephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto ue0: 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: 0xff98-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. ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
On Sun, April 4, 2010 22:12, 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 wrote: >> >> > On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: >> > >> > [...] >> > >> > > >> I changed and got this: >> > > >> >> > > >> miibus1: on axe0 >> > > >> ukphy0: 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: on axe0 >> > > >> ue0: Ethernet address: xx >> > > >> 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: on axe0 >> ukphy0: 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: 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 metric 0 mtu >> 1500 >> options=8 >> ether 00:11:50:e7:39:e9 >> inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 >> media: Ethernet none >> arroway# ifconfig ue0 >> ue0: flags=8843 metric 0 mtu >> 1500 >> options=8 >> ether 00:11:50:e7:39:e9 >> inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 >> media: Ethernet none (none ) >> status: active >> arroway# ifconfig ue0 >> ue0: flags=8843 metric 0 mtu >> 1500 >> options=8 >> ether 00:11:50:e7:39:e9 >> inet 10.2.1.2 netmask 0xff00 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. :-( waiting for any leads :) I bought a linksys axe based fast ethernet to see what happens. waiting till it arrives. thanks as usual, 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 ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
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 wrote: > > > On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: > > > > [...] > > > > > >> I changed and got this: > > > >> > > > >> miibus1: on axe0 > > > >> ukphy0: 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: on axe0 > > > >> ue0: Ethernet address: xx > > > >> 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: on axe0 > ukphy0: 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: 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 metric 0 mtu 1500 > options=8 > ether 00:11:50:e7:39:e9 > inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 > media: Ethernet none > arroway# ifconfig ue0 > ue0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:11:50:e7:39:e9 > inet 10.2.1.2 netmask 0xff00 broadcast 10.2.1.255 > media: Ethernet none (none ) > status: active > arroway# ifconfig ue0 > ue0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:11:50:e7:39:e9 > inet 10.2.1.2 netmask 0xff00 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. :-( ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
On Wed, 31 Mar 2010 12:06:31 -0700 Pyun YongHyeon wrote: > On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: > > [...] > > > >> I changed and got this: > > >> > > >> miibus1: on axe0 > > >> ukphy0: 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: on axe0 > > >> ue0: Ethernet address: xx > > >> 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: on axe0 ukphy0: PHY 1 on miibus1 ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949 ukphy0: 10baseT-FDX ue0: on axe0 ue0: Ethernet address: 00:11:50:e7:39:e9 ue0: link state changed to DOWN ue0: link state changed to DOWN ue0: link state changed to DOWN ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0:
Re: 10Mbps+ throughput usb based ethernet recommendation
On Fri, Mar 26, 2010 at 11:31:50PM -0300, Nenhum_de_Nos wrote: [...] > >> I changed and got this: > >> > >> miibus1: on axe0 > >> ukphy0: 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: on axe0 > >> ue0: Ethernet address: xx > >> 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? ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
On Fri, March 26, 2010 23:19, Pyun YongHyeon wrote: > On Fri, Mar 26, 2010 at 11:03:50PM -0300, Nenhum_de_Nos wrote: >> >> On Fri, March 26, 2010 16:50, Pyun YongHyeon wrote: >> > On Thu, Mar 25, 2010 at 09:57:22PM -0300, Nenhum_de_Nos wrote: >> > >> > [...] >> > >> >> >> miibus1: on axe0 >> >> >> ukphy0: 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. >> >> >> > >> > Ok, would you try attached patch and check whether the patch prints >> > some error messages on your console? I guess some commands are >> > timed out here. >> >> ugen1.3: at usbus1 >> axe0: on usbus1 >> axe0: PHYADDR 0xe0:0x01 >> miibus1: on axe0 >> ukphy0: PHY 1 on miibus1 >> ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 >> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> ue0: on axe0 >> ue0: Ethernet address: xx.xx.xx.xx.xx.xx >> ue0: link state changed to DOWN >> ue0: link state changed to UP >> ue0: link state changed to DOWN >> ue0: link state changed to UP >> ue0: link state changed to DOWN >> ue0: link state changed to UP >> wlan0: link state changed to UP >> ue0: link state changed to DOWN >> ue0: link state changed to UP >> vboxnet0: Ethernet address: 0a:00:27:00:00:00 >> nfe0: promiscuous mode enabled >> wlan0: link state changed to DOWN >> wlan0: link state changed to UP >> ue0: link state changed to DOWN >> ue0: link state changed to UP >> wlan0: link state changed to DOWN >> wlan0: link state changed to UP >> ue0: link state changed to DOWN >> ue0: link state changed to UP >> wlan0: link state changed to DOWN >> wlan0: link state changed to UP >> ue0: link state changed to DOWN >> ue0: link state changed to UP >> wlan0: link state changed to DOWN >> wlan0: link state changed to UP >> nfe0: link state changed to UP >> wlan0: link state changed to DOWN >> wlan0: link state changed to UP >> wlan0: link state changed to DOWN >> wlan0: link state changed to UP >> wlan0: link state changed to DOWN >> wlan0: link state changed to UP >> nfe0: link state changed to DOWN >> ue0: link state changed to DOWN >> nfe0: link state changed to UP >> ue0: link state changed to UP >> wlan0: link state changed to DOWN >> wlan0: link state changed to UP >> nfe0: tx v2 error 0x6100 > > It seems you have nfe(4) Tx issues here. You may want to check > negotiated speed/duplex is correct against switch. If you have > manual media configuration instead of auto, nuke that > configuration. nfe(4) has a long standing issue when manual media > configuration is used. I'm linking my nfe0 from notebook, bridged in a vbox freebsd machine, and the usb nic. the media is auto (not manually changed since boot) on both ue0 (native freebsd), nfe0 native and em0 (guest freebsd). >> arp: xx:xx:xx:xx:xx:xx:xx is using my IP address 10.1.1.1 on ue0! >> wlan0: link state changed to DOWN >> wlan0: link state changed to UP >> wlan0: link state changed to DOWN >> wlan0: link state changed to UP >> wlan0: link state changed to DOWN >> wlan0: link state changed to UP >> wlan0: link state changed to DOWN >> wlan0: link state changed to UP >> >> so far, just this after plugging the usb nic. tested iperf and the >> behavior was the same, but nothing in logs. >> >> just noticed this: >> >> ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 >> >> this is not the same as the other mail. I think is the same adapter (as >> I >> have two), but this should change with the nic change ? >> >> I changed and got this: >> >> miibus1: on axe0 >> ukphy0: 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 ? >> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> ue0: on axe0 >> ue0: Ethernet address: xx >> 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 :) 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/Postin
Re: 10Mbps+ throughput usb based ethernet recommendation
On Fri, Mar 26, 2010 at 11:03:50PM -0300, Nenhum_de_Nos wrote: > > On Fri, March 26, 2010 16:50, Pyun YongHyeon wrote: > > On Thu, Mar 25, 2010 at 09:57:22PM -0300, Nenhum_de_Nos wrote: > > > > [...] > > > >> >> miibus1: on axe0 > >> >> ukphy0: 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. > >> > > > > Ok, would you try attached patch and check whether the patch prints > > some error messages on your console? I guess some commands are > > timed out here. > > ugen1.3: at usbus1 > axe0: on usbus1 > axe0: PHYADDR 0xe0:0x01 > miibus1: on axe0 > ukphy0: PHY 1 on miibus1 > ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > ue0: on axe0 > ue0: Ethernet address: xx.xx.xx.xx.xx.xx > ue0: link state changed to DOWN > ue0: link state changed to UP > ue0: link state changed to DOWN > ue0: link state changed to UP > ue0: link state changed to DOWN > ue0: link state changed to UP > wlan0: link state changed to UP > ue0: link state changed to DOWN > ue0: link state changed to UP > vboxnet0: Ethernet address: 0a:00:27:00:00:00 > nfe0: promiscuous mode enabled > wlan0: link state changed to DOWN > wlan0: link state changed to UP > ue0: link state changed to DOWN > ue0: link state changed to UP > wlan0: link state changed to DOWN > wlan0: link state changed to UP > ue0: link state changed to DOWN > ue0: link state changed to UP > wlan0: link state changed to DOWN > wlan0: link state changed to UP > ue0: link state changed to DOWN > ue0: link state changed to UP > wlan0: link state changed to DOWN > wlan0: link state changed to UP > nfe0: link state changed to UP > wlan0: link state changed to DOWN > wlan0: link state changed to UP > wlan0: link state changed to DOWN > wlan0: link state changed to UP > wlan0: link state changed to DOWN > wlan0: link state changed to UP > nfe0: link state changed to DOWN > ue0: link state changed to DOWN > nfe0: link state changed to UP > ue0: link state changed to UP > wlan0: link state changed to DOWN > wlan0: link state changed to UP > nfe0: tx v2 error 0x6100 It seems you have nfe(4) Tx issues here. You may want to check negotiated speed/duplex is correct against switch. If you have manual media configuration instead of auto, nuke that configuration. nfe(4) has a long standing issue when manual media configuration is used. > arp: xx:xx:xx:xx:xx:xx:xx is using my IP address 10.1.1.1 on ue0! > wlan0: link state changed to DOWN > wlan0: link state changed to UP > wlan0: link state changed to DOWN > wlan0: link state changed to UP > wlan0: link state changed to DOWN > wlan0: link state changed to UP > wlan0: link state changed to DOWN > wlan0: link state changed to UP > > so far, just this after plugging the usb nic. tested iperf and the > behavior was the same, but nothing in logs. > > just noticed this: > > ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 > > this is not the same as the other mail. I think is the same adapter (as I > have two), but this should change with the nic change ? > > I changed and got this: > > miibus1: on axe0 > ukphy0: 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. > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > ue0: on axe0 > ue0: Ethernet address: xx > 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. ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
On Fri, March 26, 2010 16:50, Pyun YongHyeon wrote: > On Thu, Mar 25, 2010 at 09:57:22PM -0300, Nenhum_de_Nos wrote: > > [...] > >> >> miibus1: on axe0 >> >> ukphy0: 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. >> > > Ok, would you try attached patch and check whether the patch prints > some error messages on your console? I guess some commands are > timed out here. ugen1.3: at usbus1 axe0: on usbus1 axe0: PHYADDR 0xe0:0x01 miibus1: on axe0 ukphy0: PHY 1 on miibus1 ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ue0: on axe0 ue0: Ethernet address: xx.xx.xx.xx.xx.xx ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP wlan0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP vboxnet0: Ethernet address: 0a:00:27:00:00:00 nfe0: promiscuous mode enabled wlan0: link state changed to DOWN wlan0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP nfe0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP nfe0: link state changed to DOWN ue0: link state changed to DOWN nfe0: link state changed to UP ue0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP nfe0: tx v2 error 0x6100 arp: xx:xx:xx:xx:xx:xx:xx is using my IP address 10.1.1.1 on ue0! wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP so far, just this after plugging the usb nic. tested iperf and the behavior was the same, but nothing in logs. just noticed this: ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 this is not the same as the other mail. I think is the same adapter (as I have two), but this should change with the nic change ? I changed and got this: miibus1: on axe0 ukphy0: PHY 1 on miibus1 ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ue0: on axe0 ue0: Ethernet address: xx ue0: link state changed to DOWN so it didn't now. other thing is that not every time it works: ugen1.3: at usbus1 axe0: on usbus1 axe0: PHYADDR 0xe0:0x01 axe0: MII without any PHY ugen1.3: at usbus1 (disconnected) axe0: at uhub1, port 3, addr 3 (disconnected) ugen1.3: at usbus1 axe0: on usbus1 axe0: PHYADDR 0xe0:0x01 axe0: MII without any PHY ugen1.3: at usbus1 (disconnected) axe0: at uhub1, port 3, addr 3 (disconnected) and in the third time it found the PHY it was looking for above and got what I said above. hope it helps, thanks, matheus >> 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 ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
On Thu, Mar 25, 2010 at 09:57:22PM -0300, Nenhum_de_Nos wrote:
[...]
> >> miibus1: on axe0
> >> ukphy0: 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.
>
Ok, would you try attached patch and check whether the patch prints
some error messages on your console? I guess some commands are
timed out here.
> 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?
> >
Index: sys/dev/usb/net/if_axe.c
===
--- sys/dev/usb/net/if_axe.c(revision 205700)
+++ sys/dev/usb/net/if_axe.c(working copy)
@@ -295,7 +295,7 @@
{
struct axe_softc *sc = device_get_softc(dev);
uint16_t val;
- int locked;
+ int error, locked;
if (sc->sc_phyno != phy)
return (0);
@@ -304,9 +304,15 @@
if (!locked)
AXE_LOCK(sc);
- axe_cmd(sc, AXE_CMD_MII_OPMODE_SW, 0, 0, NULL);
- axe_cmd(sc, AXE_CMD_MII_READ_REG, reg, phy, &val);
- axe_cmd(sc, AXE_CMD_MII_OPMODE_HW, 0, 0, NULL);
+ error = axe_cmd(sc, AXE_CMD_MII_OPMODE_SW, 0, 0, NULL);
+ if (error != 0)
+ printf("AXE_CMD_MII_OPMODE_SW failed : %d:%d\n", reg, error);
+ error = axe_cmd(sc, AXE_CMD_MII_READ_REG, reg, phy, &val);
+ if (error != 0)
+ printf("AXE_CMD_MII_READ_REG failed : %d:%d\n", reg, error);
+ error = axe_cmd(sc, AXE_CMD_MII_OPMODE_HW, 0, 0, NULL);
+ if (error != 0)
+ printf("AXE_CMD_MII_OPMODE_HW failed : %d:%d\n", reg, error);
val = le16toh(val);
if ((sc->sc_flags & AXE_FLAG_772) != 0 && reg == MII_BMSR) {
___
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"
Re: 10Mbps+ throughput usb based ethernet recommendation
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 >> metric >> >> 0 >> >> >> mtu >> >> >> > > >> 1500 >> >> >> > > >> ether 00:11:50:e7:39:e9 >> >> >> > > >> inet 192.168.1.1 netmask 0xff00 broadcast >> 192.168.1.255 >> >> >> > > >> media: Ethernet autoselect (1000baseT ) >> >> >> > > >> status: active >> >> >> > > >> and: >> >> >> > > >> ue0: flags=8843 >> metric >> >> 0 >> >> >> mtu >> >> >> > > >> 1500 >> >> >> > > >> ether 00:11:50:e7:39:e9 >> >> >> > > >> inet 192.168.1.1 netmask 0xff00 broadcast >> 192.168.1.255 >> >> >> > > >> media: Ethernet autoselect (100baseTX >> >> ) >> >> >> > > > >> >> >> > > > >> >> >> > > >> 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 = 0x, ID2 = 0x". >> >> >> >> >> > >> >> > 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: 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: at usbus1 >> >> Mar 25 14:16:19 darkside kernel: axe0: > >> 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: on axe0 >> >> Mar 25 14:16:20 darkside kernel: ukphy0: > >> 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: on axe0 >> >> Mar 25 14:16:20 darkside kernel: ue0: Ethernet address: >>
Re: 10Mbps+ throughput usb based ethernet recommendation
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 metric > >> 0 > >> >> mtu > >> >> > > >> 1500 > >> >> > > >> ether 00:11:50:e7:39:e9 > >> >> > > >> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > >> >> > > >> media: Ethernet autoselect (1000baseT ) > >> >> > > >> status: active > >> >> > > >> and: > >> >> > > >> ue0: flags=8843 metric > >> 0 > >> >> mtu > >> >> > > >> 1500 > >> >> > > >> ether 00:11:50:e7:39:e9 > >> >> > > >> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > >> >> > > >> media: Ethernet autoselect (100baseTX > >> ) > >> >> > > > > >> >> > > > > >> >> > > >> 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 = 0x, ID2 = 0x". > >> >> > >> > > >> > 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: 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: at usbus1 > >> Mar 25 14:16:19 darkside kernel: axe0: >> 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: on axe0 > >> Mar 25 14:16:20 darkside kernel: ukphy0: >> 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: 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 r
Re: 10Mbps+ throughput usb based ethernet recommendation
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 metric >> 0 >> >> mtu >> >> > > >> 1500 >> >> > > >>ether 00:11:50:e7:39:e9 >> >> > > >>inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 >> >> > > >>media: Ethernet autoselect (1000baseT ) >> >> > > >>status: active >> >> > > >> and: >> >> > > >> ue0: flags=8843 metric >> 0 >> >> mtu >> >> > > >> 1500 >> >> > > >>ether 00:11:50:e7:39:e9 >> >> > > >>inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 >> >> > > >>media: Ethernet autoselect (100baseTX >> ) >> >> > > > >> >> > > > >> >> > > >>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 = 0x, ID2 = 0x". >> >> >> > >> > 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: 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: at usbus1 >> Mar 25 14:16:19 darkside kernel: axe0: > 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: on axe0 >> Mar 25 14:16:20 darkside kernel: ukphy0: > 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: 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: on axe0 ukphy0: PHY 1 on miibus1 ukphy0: XXX ID1 = 0x7949, ID2 = 0x79
Re: 10Mbps+ throughput usb based ethernet recommendation
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 metric 0 > >> mtu > >> > > >> 1500 > >> > > >> ether 00:11:50:e7:39:e9 > >> > > >> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > >> > > >> media: Ethernet autoselect (1000baseT ) > >> > > >> status: active > >> > > >> and: > >> > > >> ue0: flags=8843 metric 0 > >> mtu > >> > > >> 1500 > >> > > >> ether 00:11:50:e7:39:e9 > >> > > >> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > >> > > >> media: Ethernet autoselect (100baseTX ) > >> > > > > >> > > > > >> > > >> 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 = 0x, ID2 = 0x". > >> > > > > 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: 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: at usbus1 > Mar 25 14:16:19 darkside kernel: axe0: 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: on axe0 > Mar 25 14:16:20 darkside kernel: ukphy0: 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: 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. ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
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 metric 0 >> mtu >> > > >> 1500 >> > > >> ether 00:11:50:e7:39:e9 >> > > >> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 >> > > >> media: Ethernet autoselect (1000baseT ) >> > > >> status: active >> > > >> and: >> > > >> ue0: flags=8843 metric 0 >> mtu >> > > >> 1500 >> > > >> ether 00:11:50:e7:39:e9 >> > > >> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 >> > > >> media: Ethernet autoselect (100baseTX ) >> > > > >> > > > >> > > >> 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 = 0x, ID2 = 0x". >> > > 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: 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: 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: at usbus1 Mar 25 14:16:19 darkside kernel: axe0: on usbus1 Mar 25 14:16:19 darkside kernel: axe0: PHYADDR 0xe0:0x01 Mar 25 14:16:20 darkside kernel: miibus1: on axe0 Mar 25 14:16:20 darkside kernel: ukphy0: 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: 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) media keeps looping though: ue0: flags=8843 metric 0 mtu 1500 ether 00:11:50:e7:39:e9 inet 192.168.1.2 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active [r...@xxx ~]# ifconfig ue0 ue0: flags=8843 metric 0 mtu 1500 ether 00:11:50:e7:39:e9 inet 192.168.1.2 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active 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 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/fre
Re: 10Mbps+ throughput usb based ethernet recommendation
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 metric 0 mtu > > > >> 1500 > > > >>ether 00:11:50:e7:39:e9 > > > >>inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > > > >>media: Ethernet autoselect (1000baseT ) > > > >>status: active > > > >> and: > > > >> ue0: flags=8843 metric 0 mtu > > > >> 1500 > > > >>ether 00:11:50:e7:39:e9 > > > >>inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > > > >>media: Ethernet autoselect (100baseTX ) > > > > > > > >>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 = 0x, ID2 = 0x". > Use this patch instead of previous one. Index: sys/dev/mii/ukphy.c === --- sys/dev/mii/ukphy.c (revision 205608) +++ sys/dev/mii/ukphy.c (working copy) @@ -141,6 +141,8 @@ device_printf(dev, "OUI 0x%06x, model 0x%04x, rev. %d\n", MII_OUI(ma->mii_id1, ma->mii_id2), MII_MODEL(ma->mii_id2), MII_REV(ma->mii_id2)); + device_printf(dev, "XXX ID1 = 0x%04x, ID2 = 0x%04x\n", + ma->mii_id1, ma->mii_id2); sc->mii_inst = mii->mii_instance; sc->mii_phy = ma->mii_phyno; ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
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 metric 0 mtu > > >> 1500 > > >> ether 00:11:50:e7:39:e9 > > >> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > > >> media: Ethernet autoselect (1000baseT ) > > >> status: active > > >> and: > > >> ue0: flags=8843 metric 0 mtu > > >> 1500 > > >> ether 00:11:50:e7:39:e9 > > >> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > > >> media: Ethernet autoselect (100baseTX ) > > > > > >> 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 = 0x, ID2 = 0x". > > > > I'm trying to test it on current, but I think it will be the same (I saw > > cvs commits till releng 8 creating and all commits are the same ). > > > > Unless we fix the PHY issue you would get the same result on > stable/8. > > > still looking for better performance usb nic :) you think the slower > > linksys usb200m (axe based also) will have better luck in this link > > negotiation issue ? (I don't need gigabit, just to break the 10Mbps at > > I have no experience with usb200m so I don't know. > > > start - though breaking the 50Mpbs would be perfert). > > > > thanks, ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
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 metric 0 mtu > >> 1500 > >>ether 00:11:50:e7:39:e9 > >>inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > >>media: Ethernet autoselect (1000baseT ) > >>status: active > >> and: > >> ue0: flags=8843 metric 0 mtu > >> 1500 > >>ether 00:11:50:e7:39:e9 > >>inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > >>media: Ethernet autoselect (100baseTX ) > > > >>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? > > I'm trying to test it on current, but I think it will be the same (I saw > cvs commits till releng 8 creating and all commits are the same ). > Unless we fix the PHY issue you would get the same result on stable/8. > still looking for better performance usb nic :) you think the slower > linksys usb200m (axe based also) will have better luck in this link > negotiation issue ? (I don't need gigabit, just to break the 10Mbps at I have no experience with usb200m so I don't know. > start - though breaking the 50Mpbs would be perfert). > > thanks, ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote: > On Tue, Mar 23, 2010 at 12:13:26AM -0300, Nenhum_de_Nos wrote: >> >> On Mon, March 22, 2010 23:29, Nenhum_de_Nos wrote: >> > >> > >> > On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote: >> >> On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote: >> >>> hail, >> >>> >> >>> I need an usb nic that is able to push more then 10Mbps on wire. if >> is >> > altq capable better. >> >>> >> >> >> >> AFAIK all USB ethernet drivers support altq(4). >> >> >> >>> I use pfsense as router, but my next upgrade will use 10Mbps link >> and >> > my aue and rue nic's can't pass the 5Mbps barrier. I need to use three >> > to make 11Mbps on it, and its not a good thing for me in production. >> >>> >> >>> I've seen some axe based on its manual page, but I'm afraid to buy >> and >> >>> it >> >>> won't solve my problem. if anyone has any leads/experience on this >> >>> please >> >>> broadcast :) >> >>> >> >> >> >> Last time I tried AX88178 based axe(4) controller, I can push more >> than >> > 200Mbps. Related change already MFCed to stable/8. >> > >> > well, I did that but using that chip on windows :( >> > >> > I got two nics based on these chips but they are unstable as hell in >> > FreeBSD. on pfSense (FreeBSD 7.1 and 7.2 versions) I never got the >> axe0 >> > media to be active. on 8-stable (this box), one got issues with media >> link >> > and the other can set link state ok, but looses 10% of ping packets. >> iperf >> > gets cut every now and then and this makes the throughput suffer :( >> > >> > I plan to use pfSense 1.2.3 (7.2 based) and when available pfSense 2.0 >> > (8.0 based). >> > >> > are there any patches to try ? it is really unstable here ... >> > >> > some logs: >> > >> > Client connecting to 192.168.1.2, TCP port 5001 >> > TCP window size: 32.5 KByte (default) >> > >> > [ 3] local 192.168.1.1 port 42556 connected with 192.168.1.2 port >> 5001 >> > [ ID] Interval Transfer Bandwidth >> > [ 3] 0.0-32.7 sec 69.5 MBytes 17.8 Mbits/sec >> > [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 >> > >> > Client connecting to 192.168.1.2, TCP port 5001 >> > TCP window size: 32.5 KByte (default) >> > >> > [ 3] local 192.168.1.1 port 45725 connected with 192.168.1.2 port >> 5001 >> > [ ID] Interval Transfer Bandwidth >> > [ 3] 0.0-30.6 sec128 MBytes 35.1 Mbits/sec >> > [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 >> > >> > Client connecting to 192.168.1.2, TCP port 5001 >> > TCP window size: 32.5 KByte (default) >> > >> > [ 3] local 192.168.1.1 port 38546 connected with 192.168.1.2 port >> 5001 >> > [ ID] Interval Transfer Bandwidth >> > [ 3] 0.0-31.0 sec129 MBytes 35.0 Mbits/sec >> > >> > this is: >> > >> > FreeBSD xxx 8.0-STABLE FreeBSD 8.0-STABLE #7: Sun Mar 21 03:45:47 BRT >> 2010 >> > r...@xxx:/usr/obj/usr/src/sys/xxx amd64 >> > >> > and on both ends there is a nic using this chip, here is this freebsd >> and >> > the other on windows xp. >> > >> > as said above, when run iperf on this nic on windows and my nfe >> gigabit I >> > got those 228Mbps said above. >> > >> > 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 >> > >> > >> > >> > -- >> > 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 >> > ___ >> > 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" >> > >> >> Just adding info, I keep getting these outputs from ifconfig: >> >> ue0: flags=8843 metric 0 mtu >> 1500 >> ether 00:11:50:e7:39:e9 >> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 >> media: Ethernet autoselect (1000baseT ) >> status: active >> and: >> ue0: flags=8843 metric 0 mtu >> 1500 >> ether 00:11:50:e7:39:e9 >> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 >> media: Ethernet autoselect (100baseTX ) > >> 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 e
Re: 10Mbps+ throughput usb based ethernet recommendation
On Tue, Mar 23, 2010 at 12:13:26AM -0300, Nenhum_de_Nos wrote: > > On Mon, March 22, 2010 23:29, Nenhum_de_Nos wrote: > > > > > > On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote: > >> On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote: > >>> hail, > >>> > >>> I need an usb nic that is able to push more then 10Mbps on wire. if is > > altq capable better. > >>> > >> > >> AFAIK all USB ethernet drivers support altq(4). > >> > >>> I use pfsense as router, but my next upgrade will use 10Mbps link and > > my aue and rue nic's can't pass the 5Mbps barrier. I need to use three > > to make 11Mbps on it, and its not a good thing for me in production. > >>> > >>> I've seen some axe based on its manual page, but I'm afraid to buy and > >>> it > >>> won't solve my problem. if anyone has any leads/experience on this > >>> please > >>> broadcast :) > >>> > >> > >> Last time I tried AX88178 based axe(4) controller, I can push more than > > 200Mbps. Related change already MFCed to stable/8. > > > > well, I did that but using that chip on windows :( > > > > I got two nics based on these chips but they are unstable as hell in > > FreeBSD. on pfSense (FreeBSD 7.1 and 7.2 versions) I never got the axe0 > > media to be active. on 8-stable (this box), one got issues with media link > > and the other can set link state ok, but looses 10% of ping packets. iperf > > gets cut every now and then and this makes the throughput suffer :( > > > > I plan to use pfSense 1.2.3 (7.2 based) and when available pfSense 2.0 > > (8.0 based). > > > > are there any patches to try ? it is really unstable here ... > > > > some logs: > > > > Client connecting to 192.168.1.2, TCP port 5001 > > TCP window size: 32.5 KByte (default) > > > > [ 3] local 192.168.1.1 port 42556 connected with 192.168.1.2 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-32.7 sec 69.5 MBytes 17.8 Mbits/sec > > [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 > > > > Client connecting to 192.168.1.2, TCP port 5001 > > TCP window size: 32.5 KByte (default) > > > > [ 3] local 192.168.1.1 port 45725 connected with 192.168.1.2 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-30.6 sec128 MBytes 35.1 Mbits/sec > > [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 > > > > Client connecting to 192.168.1.2, TCP port 5001 > > TCP window size: 32.5 KByte (default) > > > > [ 3] local 192.168.1.1 port 38546 connected with 192.168.1.2 port 5001 > > [ ID] Interval Transfer Bandwidth > > [ 3] 0.0-31.0 sec129 MBytes 35.0 Mbits/sec > > > > this is: > > > > FreeBSD xxx 8.0-STABLE FreeBSD 8.0-STABLE #7: Sun Mar 21 03:45:47 BRT 2010 > > r...@xxx:/usr/obj/usr/src/sys/xxx amd64 > > > > and on both ends there is a nic using this chip, here is this freebsd and > > the other on windows xp. > > > > as said above, when run iperf on this nic on windows and my nfe gigabit I > > got those 228Mbps said above. > > > > 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 > > > > > > > > -- > > 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 > > ___ > > 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" > > > > Just adding info, I keep getting these outputs from ifconfig: > > ue0: flags=8843 metric 0 mtu 1500 > ether 00:11:50:e7:39:e9 > inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > media: Ethernet autoselect (1000baseT ) > status: active > and: > ue0: flags=8843 metric 0 mtu 1500 > ether 00:11:50:e7:39:e9 > inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > 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? Would you show me the output of "devinfo -rv| grep phy"? > intel gigabit pcie nic: > ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubsc
Re: 10Mbps+ throughput usb based ethernet recommendation
On Mon, March 22, 2010 23:29, Nenhum_de_Nos wrote: > > > On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote: >> On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote: >>> hail, >>> >>> I need an usb nic that is able to push more then 10Mbps on wire. if is > altq capable better. >>> >> >> AFAIK all USB ethernet drivers support altq(4). >> >>> I use pfsense as router, but my next upgrade will use 10Mbps link and > my aue and rue nic's can't pass the 5Mbps barrier. I need to use three > to make 11Mbps on it, and its not a good thing for me in production. >>> >>> I've seen some axe based on its manual page, but I'm afraid to buy and >>> it >>> won't solve my problem. if anyone has any leads/experience on this >>> please >>> broadcast :) >>> >> >> Last time I tried AX88178 based axe(4) controller, I can push more than > 200Mbps. Related change already MFCed to stable/8. > > well, I did that but using that chip on windows :( > > I got two nics based on these chips but they are unstable as hell in > FreeBSD. on pfSense (FreeBSD 7.1 and 7.2 versions) I never got the axe0 > media to be active. on 8-stable (this box), one got issues with media link > and the other can set link state ok, but looses 10% of ping packets. iperf > gets cut every now and then and this makes the throughput suffer :( > > I plan to use pfSense 1.2.3 (7.2 based) and when available pfSense 2.0 > (8.0 based). > > are there any patches to try ? it is really unstable here ... > > some logs: > > Client connecting to 192.168.1.2, TCP port 5001 > TCP window size: 32.5 KByte (default) > > [ 3] local 192.168.1.1 port 42556 connected with 192.168.1.2 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-32.7 sec 69.5 MBytes 17.8 Mbits/sec > [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 > > Client connecting to 192.168.1.2, TCP port 5001 > TCP window size: 32.5 KByte (default) > > [ 3] local 192.168.1.1 port 45725 connected with 192.168.1.2 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-30.6 sec128 MBytes 35.1 Mbits/sec > [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 > > Client connecting to 192.168.1.2, TCP port 5001 > TCP window size: 32.5 KByte (default) > > [ 3] local 192.168.1.1 port 38546 connected with 192.168.1.2 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-31.0 sec129 MBytes 35.0 Mbits/sec > > this is: > > FreeBSD xxx 8.0-STABLE FreeBSD 8.0-STABLE #7: Sun Mar 21 03:45:47 BRT 2010 > r...@xxx:/usr/obj/usr/src/sys/xxx amd64 > > and on both ends there is a nic using this chip, here is this freebsd and > the other on windows xp. > > as said above, when run iperf on this nic on windows and my nfe gigabit I > got those 228Mbps said above. > > 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 > > > > -- > 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 > ___ > 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" > Just adding info, I keep getting these outputs from ifconfig: ue0: flags=8843 metric 0 mtu 1500 ether 00:11:50:e7:39:e9 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active and: ue0: flags=8843 metric 0 mtu 1500 ether 00:11:50:e7:39:e9 inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active and this keeps repeating over and over. iperf and on the other end an intel gigabit pcie nic: [r...@xxx ~]# iperf -c 192.168.1.2 -t 30 Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 52180 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-50.9 sec392 MBytes 64.6 Mbits/sec [r...@xxx ~]# iperf -c 192.168.1.2 -t 30 Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192
Re: 10Mbps+ throughput usb based ethernet recommendation
On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote: > On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote: >> hail, >> >> I need an usb nic that is able to push more then 10Mbps on wire. if is altq capable better. >> > > AFAIK all USB ethernet drivers support altq(4). > >> I use pfsense as router, but my next upgrade will use 10Mbps link and my aue and rue nic's can't pass the 5Mbps barrier. I need to use three to make 11Mbps on it, and its not a good thing for me in production. >> >> I've seen some axe based on its manual page, but I'm afraid to buy and it >> won't solve my problem. if anyone has any leads/experience on this please >> broadcast :) >> > > Last time I tried AX88178 based axe(4) controller, I can push more than 200Mbps. Related change already MFCed to stable/8. well, I did that but using that chip on windows :( I got two nics based on these chips but they are unstable as hell in FreeBSD. on pfSense (FreeBSD 7.1 and 7.2 versions) I never got the axe0 media to be active. on 8-stable (this box), one got issues with media link and the other can set link state ok, but looses 10% of ping packets. iperf gets cut every now and then and this makes the throughput suffer :( I plan to use pfSense 1.2.3 (7.2 based) and when available pfSense 2.0 (8.0 based). are there any patches to try ? it is really unstable here ... some logs: Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 42556 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-32.7 sec 69.5 MBytes 17.8 Mbits/sec [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 45725 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-30.6 sec128 MBytes 35.1 Mbits/sec [r...@darkside ~]# iperf -c 192.168.1.2 -t 30 Client connecting to 192.168.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) [ 3] local 192.168.1.1 port 38546 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-31.0 sec129 MBytes 35.0 Mbits/sec this is: FreeBSD xxx 8.0-STABLE FreeBSD 8.0-STABLE #7: Sun Mar 21 03:45:47 BRT 2010 r...@xxx:/usr/obj/usr/src/sys/xxx amd64 and on both ends there is a nic using this chip, here is this freebsd and the other on windows xp. as said above, when run iperf on this nic on windows and my nfe gigabit I got those 228Mbps said above. 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 -- 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 ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
On Mon, March 1, 2010 16:33, Pyun YongHyeon wrote: > On Mon, Mar 01, 2010 at 04:22:47PM -0300, Nenhum_de_Nos wrote: >> >> On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote: >> > On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote: >> >> hail, >> >> >> >> I need an usb nic that is able to push more then 10Mbps on wire. if >> is >> >> altq capable better. >> >> >> > >> > AFAIK all USB ethernet drivers support altq(4). >> >> first of all, thanks for the reply. >> >> but unfortunatelly I think I found one that is not, rue. at least ont >> the >> version pfsense 1.2.3 is based ... >> > > Hmm, you're right. I've checked stable/7 and rue(4) lacks altq(4) > support code. If you switch to stable/8 you can get altq(4) > capability as well as better performance. the change in 8 is really great. as my aue won't work at all (attachs, but can't send bytes). I would like to hear from people that used Linksys USB200M, as 100Mbps is enough for me and the hardware is way cheaper. it is based on the (I think older) AX88172 ... if anyone could share :) 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 ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
On Mon, Mar 01, 2010 at 04:22:47PM -0300, Nenhum_de_Nos wrote: > > On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote: > > On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote: > >> hail, > >> > >> I need an usb nic that is able to push more then 10Mbps on wire. if is > >> altq capable better. > >> > > > > AFAIK all USB ethernet drivers support altq(4). > > first of all, thanks for the reply. > > but unfortunatelly I think I found one that is not, rue. at least ont the > version pfsense 1.2.3 is based ... > Hmm, you're right. I've checked stable/7 and rue(4) lacks altq(4) support code. If you switch to stable/8 you can get altq(4) capability as well as better performance. ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
On Mon, March 1, 2010 16:10, Pyun YongHyeon wrote: > On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote: >> hail, >> >> I need an usb nic that is able to push more then 10Mbps on wire. if is >> altq capable better. >> > > AFAIK all USB ethernet drivers support altq(4). first of all, thanks for the reply. but unfortunatelly I think I found one that is not, rue. at least ont the version pfsense 1.2.3 is based ... >> I use pfsense as router, but my next upgrade will use 10Mbps link and my >> aue and rue nic's can't pass the 5Mbps barrier. I need to use three to >> make 11Mbps on it, and its not a good thing for me in production. >> >> I've seen some axe based on its manual page, but I'm afraid to buy and >> it >> won't solve my problem. if anyone has any leads/experience on this >> please >> broadcast :) >> > > Last time I tried AX88178 based axe(4) controller, I can push more > than 200Mbps. Related change already MFCed to stable/8. that's kind of a problem for me, as pfsense uses 7 yet (is about to change) > I'm not sure which FreeBSD version pfsense is based on though. 7.2+ (7.2, or a bit more new from stable). but thanks for the info ! aiming at this controller :) 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 ___ 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"
Re: 10Mbps+ throughput usb based ethernet recommendation
On Mon, Mar 01, 2010 at 03:57:02PM -0300, Nenhum_de_Nos wrote: > hail, > > I need an usb nic that is able to push more then 10Mbps on wire. if is > altq capable better. > AFAIK all USB ethernet drivers support altq(4). > I use pfsense as router, but my next upgrade will use 10Mbps link and my > aue and rue nic's can't pass the 5Mbps barrier. I need to use three to > make 11Mbps on it, and its not a good thing for me in production. > > I've seen some axe based on its manual page, but I'm afraid to buy and it > won't solve my problem. if anyone has any leads/experience on this please > broadcast :) > Last time I tried AX88178 based axe(4) controller, I can push more than 200Mbps. Related change already MFCed to stable/8. I'm not sure which FreeBSD version pfsense is based on though. ___ 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"
10Mbps+ throughput usb based ethernet recommendation
hail, I need an usb nic that is able to push more then 10Mbps on wire. if is altq capable better. I use pfsense as router, but my next upgrade will use 10Mbps link and my aue and rue nic's can't pass the 5Mbps barrier. I need to use three to make 11Mbps on it, and its not a good thing for me in production. I've seen some axe based on its manual page, but I'm afraid to buy and it won't solve my problem. if anyone has any leads/experience on this please broadcast :) 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 ___ 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"
