Re: 10Mbps+ throughput usb based ethernet recommendation
Nenhum_de_Nos
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
[root@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 sec 128 MBytes 35.1 Mbits/sec
[root@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 sec 129 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
root@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?
Nenhum_de_Nos
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-usb
> To unsubscribe, send any mail to "freebsd-usb...@freebsd.org"
>
Just adding info, I keep getting these outputs from ifconfig:
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:11:50:e7:39:e9
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
and:
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:11:50:e7:39:e9
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (100baseTX <full-duplex,hw-loopback>)
status: active
and this keeps repeating over and over. iperf and on the other end an
intel gigabit pcie nic:
[root@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 sec 392 MBytes 64.6 Mbits/sec
[root@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 62772 connected with 192.168.1.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-30.0 sec 489 MBytes 137 Mbits/sec
again it is 32MBps and gets cut down to some KBps, then again 32MBps. I
think those link negotiations are to blame, but that's a "I think" :)
Pyun YongHyeon
> 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:
>
Nenhum_de_Nos
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
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 ).
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
start - though breaking the 50Mpbs would be perfert).
thanks,
matheus
>> intel gigabit pcie nic:
Pyun YongHyeon
> On Wed, Mar 24, 2010 at 06:16:21PM -0300, Nenhum_de_Nos wrote:
> >
> > On Tue, March 23, 2010 22:01, Pyun YongHyeon wrote:
>
>
> > >> Just adding info, I keep getting these outputs from ifconfig:
> > >>
> > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> > >> 1500
> > >> ether 00:11:50:e7:39:e9
> > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> > >> media: Ethernet autoselect (1000baseT <full-duplex>)
> > >> status: active
> > >> and:
> > >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> > >> 1500
> > >> ether 00:11:50:e7:39:e9
> > >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> > >> media: Ethernet autoselect (100baseTX <full-duplex,hw-loopback>)
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >> status: active
> > >>
> > >> and this keeps repeating over and over. iperf and on the other end an
> > >
> > > Maybe this is real problem. It seems PHY have trouble to establish
> > > link. This is FreeBSD stable/8 right?
> >
> > yes. on 7.2 is even worse :(
> >
> > > Would you show me the output of "devinfo -rv| grep phy"?
> >
> > /usr/home/matheus]$ devinfo -rv| grep phy
> > ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 at phyno=1
>
> PHY driver. Otherwise it will incorrectly reprogram some registers
> and this can result in unexpected result.
> The OUI 0x1e from the above looks odd and I'm not aware of any PHY
> vendors that reports such OUI. Because FreeBSD does not strictly
> follows OUI decoding defined by IEEE it's also possible that
> FreeBSD incorrectly showed wrong OUI. What is your USB ethernet
> controller model?
>
Please try this patch and let me know the output on your console.
It will show you "XXX ID1 = 0xYYYY, ID2 = 0xZZZZ".
> >
> > 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.
Pyun YongHyeon
>
[...]
> >> Just adding info, I keep getting these outputs from ifconfig:
> >>
> >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> >> 1500
> >> ether 00:11:50:e7:39:e9
> >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> >> media: Ethernet autoselect (1000baseT <full-duplex>)
> >> status: active
> >> and:
> >> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> >> 1500
> >> ether 00:11:50:e7:39:e9
> >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> >> media: Ethernet autoselect (100baseTX <full-duplex,hw-loopback>)
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> status: active
> >>
> >> and this keeps repeating over and over. iperf and on the other end an
> >
> > Maybe this is real problem. It seems PHY have trouble to establish
> > link. This is FreeBSD stable/8 right?
>
> yes. on 7.2 is even worse :(
>
> > Would you show me the output of "devinfo -rv| grep phy"?
>
> /usr/home/matheus]$ devinfo -rv| grep phy
> ukphy0 pnpinfo oui=0x1e model=0x14 rev=0x9 at phyno=1
axe(4) requires correct resolved speed/link status reported from
PHY driver. Otherwise it will incorrectly reprogram some registers
and this can result in unexpected result.
The OUI 0x1e from the above looks odd and I'm not aware of any PHY
vendors that reports such OUI. Because FreeBSD does not strictly
follows OUI decoding defined by IEEE it's also possible that
FreeBSD incorrectly showed wrong OUI. What is your USB ethernet
controller model?
>
> 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,
Nenhum_de_Nos
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: <vendor 0x050d> at usbus1
(disconnected)
Mar 25 14:15:59 darkside kernel: axe0: at uhub1, port 3, addr 4
(disconnected)
Mar 25 14:15:59 darkside kernel: ukphy0: detached
Mar 25 14:15:59 darkside kernel: miibus1: detached
Mar 25 14:16:00 darkside kernel: nfe0: link state changed to DOWN
Mar 25 14:16:19 darkside kernel: ugen1.4: <vendor 0x050d> at usbus1
Mar 25 14:16:19 darkside kernel: axe0: <vendor 0x050d product 0x5055, rev
2.00/0.01, addr 4> on usbus1
Mar 25 14:16:19 darkside kernel: axe0: PHYADDR 0xe0:0x01
Mar 25 14:16:20 darkside kernel: miibus1: <MII bus> on axe0
Mar 25 14:16:20 darkside kernel: ukphy0: <Generic IEEE 802.3u media
interface> PHY 1 on miibus1
Mar 25 14:16:20 darkside kernel: ukphy0: 10baseT, 10baseT-FDX, 100baseTX,
100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
Mar 25 14:16:20 darkside kernel: ue0: <USB Ethernet> on axe0
Mar 25 14:16:20 darkside kernel: ue0: Ethernet address: 00:11:50:e7:39:e9
Mar 25 14:16:21 darkside kernel: ue0: link state changed to DOWN
Mar 25 14:16:23 darkside kernel: nfe0: link state changed to UP
Mar 25 14:17:06 darkside kernel: ue0: link state changed to UP
do I need to recompile kernel ? (I will as soon as I get home anyway)
media keeps looping though:
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:11:50:e7:39:e9
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT <full-duplex,hw-loopback>)
status: active
[root@xxx ~]# ifconfig ue0
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:11:50:e7:39:e9
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
Pyun YongHyeon
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.
Yes, mii(4) should be recompiled to get the register information.
Let me know ukphy(4) output after rebuilding kernel.
Nenhum_de_Nos
there you are:
miibus1: <MII bus> on axe0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX,
1000baseT, 1000baseT-FDX, auto
ue0: <USB Ethernet> on axe0
ue0: Ethernet address: xx:xx:xx:xx:xx:xx
let me know if you need anything else :)
Pyun YongHyeon
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.
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?
Nenhum_de_Nos
:(
>> 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.
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?
>
Pyun YongHyeon
[...]
> >> miibus1: <MII bus> on axe0
> >> ukphy0: <Generic IEEE 802.3u media interface> 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.
Nenhum_de_Nos
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: <MII bus> on axe0
>> >> ukphy0: <Generic IEEE 802.3u media interface> 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: <vendor 0x050d> at usbus1
axe0: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3> on usbus1
axe0: PHYADDR 0xe0:0x01
miibus1: <MII bus> on axe0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
ue0: <USB Ethernet> 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: <MII bus> on axe0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
ue0: <USB Ethernet> on axe0
ue0: Ethernet address: xxxxxxxxxxxxxx
ue0: link state changed to DOWN
so it didn't now. other thing is that not every time it works:
ugen1.3: <vendor 0x050d> at usbus1
axe0: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3> on usbus1
axe0: PHYADDR 0xe0:0x01
axe0: MII without any PHY
ugen1.3: <vendor 0x050d> at usbus1 (disconnected)
axe0: at uhub1, port 3, addr 3 (disconnected)
ugen1.3: <vendor 0x050d> at usbus1
axe0: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3> on usbus1
axe0: PHYADDR 0xe0:0x01
axe0: MII without any PHY
ugen1.3: <vendor 0x050d> 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?
>> >
>
Pyun YongHyeon
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: <MII bus> on axe0
> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
> ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is *NOT* bogus value. It's Agere Systems' ET1011 gigabit PHY.
FreeBSD has truephy(4) for Agere Systems' PHY but it does not have
support code for the model yet.
> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto
> ue0: <USB Ethernet> on axe0
> ue0: Ethernet address: xxxxxxxxxxxxxx
> ue0: link state changed to DOWN
>
> so it didn't now. other thing is that not every time it works:
>
Yeah, that is real issue here. I guess there should be some magic
to wakeup the PHY from deep sleep state. I'll see what can be done.
Nenhum_de_Nos
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: <MII bus> on axe0
>> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
>> ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This is *NOT* bogus value. It's Agere Systems' ET1011 gigabit PHY.
> FreeBSD has truephy(4) for Agere Systems' PHY but it does not have
> support code for the model yet.
so I can think that's the issue, right ?
>> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
>> 1000baseT-FDX, auto
>> ue0: <USB Ethernet> on axe0
>> ue0: Ethernet address: xxxxxxxxxxxxxx
>> ue0: link state changed to DOWN
>>
>> so it didn't now. other thing is that not every time it works:
>>
>
> Yeah, that is real issue here. I guess there should be some magic
> to wakeup the PHY from deep sleep state. I'll see what can be done.
ok, great it was found :)
let me know if I can help in anything :)
matheus
Pyun YongHyeon
[...]
> >> I changed and got this:
> >>
> >> miibus1: <MII bus> on axe0
> >> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
> >> ukphy0: XXX ID1 = 0x0282, ID2 = 0xf012
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > This is *NOT* bogus value. It's Agere Systems' ET1011 gigabit PHY.
> > FreeBSD has truephy(4) for Agere Systems' PHY but it does not have
> > support code for the model yet.
>
> so I can think that's the issue, right ?
Probably. But this does not explain sometimes why you get some
bogus value form PHY id registers.
>
> >> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> >> 1000baseT-FDX, auto
> >> ue0: <USB Ethernet> on axe0
> >> ue0: Ethernet address: xxxxxxxxxxxxxx
> >> ue0: link state changed to DOWN
> >>
> >> so it didn't now. other thing is that not every time it works:
> >>
> >
> > Yeah, that is real issue here. I guess there should be some magic
> > to wakeup the PHY from deep sleep state. I'll see what can be done.
>
> ok, great it was found :)
>
> let me know if I can help in anything :)
>
Would you try attached patch and let me know how it goes?
Nenhum_de_Nos
axe0: PHYADDR 0xe0:0x01
miibus1: <MII bus> on axe0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
ukphy0: XXX ID1 = 0x7949, ID2 = 0x7949
ukphy0: 10baseT-FDX
ue0: <USB Ethernet> 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: 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
and I can't ping the other host :(
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
ether 00:11:50:e7:39:e9
inet 10.2.1.2 netmask 0xffffff00 broadcast 10.2.1.255
media: Ethernet none
arroway# ifconfig ue0
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
ether 00:11:50:e7:39:e9
inet 10.2.1.2 netmask 0xffffff00 broadcast 10.2.1.255
media: Ethernet none (none <hw-loopback>)
status: active
arroway# ifconfig ue0
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
ether 00:11:50:e7:39:e9
inet 10.2.1.2 netmask 0xffffff00 broadcast 10.2.1.255
media: Ethernet none
and it is still crazy media changing.
thanks,
Pyun YongHyeon
Due to other issues previous patch didn't have chance to make it
work. This time, PHY id started to reporting garbage again which
means all MII register access may return garbage too. Don't know
this could be related with USB subsystem though.
> ukphy0: 10baseT-FDX
> ue0: <USB Ethernet> on axe0
> ue0: Ethernet address: 00:11:50:e7:39:e9
> ue0: link state changed to DOWN
[...]
> and I can't ping the other host :(
>
> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=80000<LINKSTATE>
> ether 00:11:50:e7:39:e9
> inet 10.2.1.2 netmask 0xffffff00 broadcast 10.2.1.255
> media: Ethernet none
> arroway# ifconfig ue0
> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=80000<LINKSTATE>
> ether 00:11:50:e7:39:e9
> inet 10.2.1.2 netmask 0xffffff00 broadcast 10.2.1.255
> media: Ethernet none (none <hw-loopback>)
> status: active
> arroway# ifconfig ue0
> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=80000<LINKSTATE>
> ether 00:11:50:e7:39:e9
> inet 10.2.1.2 netmask 0xffffff00 broadcast 10.2.1.255
> media: Ethernet none
>
> and it is still crazy media changing.
>
Because your PHY is not recognized it's expected result. :-(
Nenhum_de_Nos
waiting for any leads :)
I bought a linksys axe based fast ethernet to see what happens. waiting
till it arrives.
thanks as usual,
Pyun YongHyeon
Today I got ordered Belkin F5D5055 USB controller. And I believe
this controller is the same one as you have. With the previous patch
it worked as expected on my box.
axe0: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 2> on
usbus7
axe0: PHYADDR 0xe0:0x01
miibus0: <MII bus> on axe0
truephy0: <ET1011 10/100/1000baseT PHY> PHY 1 on miibus0
truephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
ue0: <USB Ethernet> on axe0
ue0: Ethernet address: 00:22:75:d6:ab:88
ue0: link state changed to DOWN
ue0: link state changed to UP
And the performance number for the controller is also similar to
other AX88178 gigabit controllers. So I guess axe(4) has no issue
in handling Belkin F5D5055 USB controller but underlying ehci(4)
could be behaving incorrectly. I believe this part could be
explained/debugged by Hans.
Mine is the following.
ehci1 pnpinfo vendor=0x8086 device=0x3a6a subvendor=0x1028 subdevice=0x027f class=0x0c0320 at slot=29 function=7
Interrupt request lines:
23
I/O memory addresses:
0xff980000-0xff9803ff
usbus7
uhub7
axe0 pnpinfo vendor=0x050d product=0x5055 devclass=0xff devsubclass=0xff sernum="" release=0x0001 intclass=0xff intsubclass=0xff at port=5 interface=0
miibus0
truephy0 pnpinfo oui=0xa0bc model=0x1 rev=0x4 at phyno=1
Hope this helps.