usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short
period of traffic
Nenhum_de_Nos
matheus at eternamente.info
Fri Nov 19 20:24:06 UTC 2010
On Fri, November 19, 2010 17:27, Pyun YongHyeon wrote:
> On Fri, Nov 19, 2010 at 04:23:20PM -0200, Nenhum_de_Nos wrote:
>>
>> On Fri, November 19, 2010 15:13, Pyun YongHyeon wrote:
>> > On Fri, Nov 19, 2010 at 03:19:26AM -0200, Nenhum_de_Nos wrote:
>> >>
>> >> On Thu, November 18, 2010 23:38, Pyun YongHyeon wrote:
>> >> > On Thu, Nov 18, 2010 at 10:40:10PM -0200, Nenhum_de_Nos wrote:
>> >> >>
>> >> >> On Thu, November 18, 2010 22:06, Pyun YongHyeon wrote:
>> >> >> > On Thu, Nov 18, 2010 at 09:12:13PM -0200, Nenhum_de_Nos wrote:
>> >> >> >>
>> >> >> >> On Thu, November 18, 2010 18:24, Pyun YongHyeon wrote:
>> >> >> >> > On Thu, Nov 18, 2010 at 04:20:51PM -0200, Nenhum_de_Nos
>> wrote:
>> >> >> >> >>
>> >> >> >> >> On Thu, November 18, 2010 13:10, Derrick Brashear wrote:
>> >> >> >> >> > The following reply was made to PR usb/140883; it has been
>> >> noted
>> >> >> by
>> >> >> >> >> GNATS.
>> >> >> >> >> >
>> >> >> >> >> > From: Derrick Brashear <shadow at gmail.com>
>> >> >> >> >> > To: bug-followup at FreeBSD.org, sub.mesa at gmail.com
>> >> >> >> >> > Cc:
>> >> >> >> >> > Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet
>> >> hangs
>> >> >> >> after
>> >> >> >> >> > short
>> >> >> >> >> > period of traffic
>> >> >> >> >> > Date: Thu, 18 Nov 2010 09:36:50 -0500
>> >> >> >> >> >
>> >> >> >> >> > Pyun has provided an updated driver which avoids several
>> >> issues
>> >> >> >> >> > including using a too-large transmit buffer (the chipset
>> >> claims
>> >> >> >> only
>> >> >> >> >> > 8k) but none of the fixes worked until he disabled frame
>> >> >> combining
>> >> >> >> >> for
>> >> >> >> >> > transmit. With only a single packet being sent per frame
>> (as
>> >> >> was
>> >> >> >> the
>> >> >> >> >> > case in FreeBSD 7, apparently) seems to make the issue go
>> >> away.
>> >> >> >> None
>> >> >> >> >> > of the cases I could use to reproduce the issue now
>> happen.
>> >> >> >> >> >
>> >> >> >> >> > --
>> >> >> >> >> > Derrick
>> >> >> >> >>
>> >> >> >> >> is this already in 8-stable ? I have a couple of axe(4)
>> based
>> >> >> nic's
>> >> >> >> >> they're not ok on 8-stable. I've talked to Pyun before, and
>> >> that
>> >> >> time
>> >> >> >> >> seemed do solve the issue (with gigabit belkin axe based)
>> but
>> >> now
>> >> >> I
>> >> >> >> >> can't
>> >> >> >> >> get them to work anymore. even fast ethernet linksys axe are
>> >> just
>> >> >> >> dying
>> >> >> >> >> when in a bridge (switched to OpenBSD to have it working).
>> >> >> >> >>
>> >> >> >> >> how ca I try this to help ?
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > I uploaded updated if_axe.c/if_axereg.h to the following URL.
>> >> >> >> > http://people.freebsd.org/~yongari/axe/if_axe.c
>> >> >> >> > http://people.freebsd.org/~yongari/axe/if_axereg.h
>> >> >> >> >
>> >> >> >> > That files seem to fix axe(4) hang which were seen on
>> AX88772A
>> >> >> >> > controller. One of most notable changes are removing
>> combining
>> >> >> >> > multiple TX frames in TX path such that this change may
>> result
>> >> in
>> >> >> >> > sub-optimal performance for most axe(4) controllers. However
>> it
>> >> >> >> > seems that change makes Derrick's controller work without
>> >> problems.
>> >> >> >> > Generally I prefer driver stability over performance so if
>> this
>> >> >> >> > change also fixes other axe(4) stability issues reported so
>> far,
>> >> I
>> >> >> >> > want to check in the change.
>> >> >> >> >
>> >> >> >> > Thanks.
>> >> >> >>
>> >> >> >> well,
>> >> >> >>
>> >> >> >> things did got better here. but the link state UP and DOWN are
>> >> still
>> >> >> >> there :(
>> >> >> >>
>> >> >> >> ugen2.3: <vendor 0x050d> at usbus2
>> >> >> >> axe1: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3> on
>> >> usbus2
>> >> >> >> axe1: PHYADDR 0xe0:0x01
>> >> >> >> miibus2: <MII bus> on axe1
>> >> >> >> ukphy2: <Generic IEEE 802.3u media interface> PHY 1 on miibus2
>> >> >> >> ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
>> >> 1000baseT,
>> >> >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> >> >> 1000baseT-FD
>> >> >> >> X, auto
>> >> >> >
>> >> >> > It seems you have PHY driver issue. Normally all gigabit PHYs
>> >> >> > should have their own PHY driver since most PHYs hardwares tend
>> to
>> >> >> > have a special register that reports link state changes.
>> >> >> > Show me the output of "devinfo -rv | grep phy".
>> >> >>
>> >> >> there you are:
>> >> >>
>> >> >> devinfo -rv|grep phy
>> >> >> ukphy1 pnpinfo oui=0xec6 model=0x1 rev=0x1 at
>> >> phyno=16
>> >> >> ukphy2 pnpinfo oui=0xa080 model=0x28 rev=0x2 at
>> >> >> phyno=1
>> >> >> ukphy0 pnpinfo oui=0x4063 model=0x32 rev=0xa at
>> phyno=1
>> >> >>
>> >> >
>> >> > Hmm.... You have many ukphys there. :-) I think the PHY attached to
>> >> > the USB controller is ukphy2. The OUI indicates its maker is ASIX.
>> >> > Unfortunately there is no dedicated PHY driver for this PHY. I
>> >> > guess it may use a modified CICADA PHY though. Updated driver to
>> >> > force GPIO configuration for this PHY. Would you try again after
>> >> > downloading if_axe.c/if_axereg.h? It may show
>> >> > "unknown PHY mode : 0xXX" if my guess is wrong.
>>
>> back to this, no problem of unknown PHY:
>>
>> ugen2.2: <vendor 0x13b1> at usbus2
>> axe0: <vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 2> on usbus2
>> axe0: PHYADDR 0xe0:0x10
>> Root mount waiting for: usbus2
>> miibus1: <MII bus> on axe0
>> ukphy1: <Generic IEEE 802.3u media interface> PHY 16 on miibus1
>> ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>> ue0: <USB Ethernet> on axe0
>> ue0: Ethernet address: my mac here
>> ugen2.3: <vendor 0x050d> at usbus2
>> axe1: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 3> on usbus2
>> axe1: PHYADDR 0xe0:0x01
>> Trying to mount root from ufs:/dev/ad0s3a
>> miibus2: <MII bus> on axe1
>> ukphy2: <Generic IEEE 802.3u media interface> PHY 1 on miibus2
>> ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
>> 1000baseT-FDX, auto
>> ue1: <USB Ethernet> on axe1
>> ue1: Ethernet address: my other mac here
>>
>> the ping still shows problems (on gbit controller at 100BaseTX):
>>
>> 62 packets transmitted, 55 packets received, 11.3% packet loss
>> round-trip min/avg/max/stddev = 0.873/1.957/51.408/6.730 ms
>>
>> when in gigabit, no good:
>>
>
> Ok, try again after downloading new if_axe.c and let me know
> the output "EEPROM data : 0xXX, phymode : 0xXX" shown on your
> console.
never got to see that message. I saw the diff to previous version, and did
boot into verbose mode (dmesg attached). there were just the belkin
gigabit nic on boot. after, the linksys USB200M:
axe1: <vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 3> on usbus2
axe1: PHYADDR 0xe0:0x10
miibus2: <MII bus> on axe1
ukphy1: <Generic IEEE 802.3u media interface> PHY 16 on miibus2
ukphy1: OUI 0x000ec6, model 0x0001, rev. 1
ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue1: <USB Ethernet> on axe1
ue1: bpf attached
invalid media SR 0x700
invalid media SR 0x700
and the other gigabit:
ugen2.4: <vendor 0x050d> at usbus2
axe2: <vendor 0x050d product 0x5055, rev 2.00/0.01, addr 4> on usbus2
axe2: PHYADDR 0xe0:0x01
miibus3: <MII bus> on axe2
truephy1: <ET1011 10/100/1000baseT PHY> PHY 1 on miibus3
truephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX,
auto
ue2: <USB Ethernet> on axe2
ue2: bpf attached
ue2: Ethernet address: my mac here
ue2: link state changed to DOWN
and never got to see the EEPROM message.
>> ping 192.168.1.3
>> PING 192.168.1.3 (192.168.1.3): 56 data bytes
>> 64 bytes from 192.168.1.3: icmp_seq=2 ttl=128 time=1.533 ms
>> 64 bytes from 192.168.1.3: icmp_seq=3 ttl=128 time=1001.806 ms
>> 64 bytes from 192.168.1.3: icmp_seq=4 ttl=128 time=1.151 ms
>> 64 bytes from 192.168.1.3: icmp_seq=5 ttl=128 time=1001.860 ms
>> 64 bytes from 192.168.1.3: icmp_seq=6 ttl=128 time=1.317 ms
>> 64 bytes from 192.168.1.3: icmp_seq=7 ttl=128 time=1.036 ms
>> 64 bytes from 192.168.1.3: icmp_seq=8 ttl=128 time=1001.899 ms
>> 64 bytes from 192.168.1.3: icmp_seq=9 ttl=128 time=1.273 ms
>> ping: sendto: No route to host
>> ping: sendto: No route to host
>> ping: sendto: No route to host
>> 64 bytes from 192.168.1.3: icmp_seq=16 ttl=128 time=0.992 ms
>> 64 bytes from 192.168.1.3: icmp_seq=18 ttl=128 time=0.860 ms
>> ping: sendto: No route to host
>> 64 bytes from 192.168.1.3: icmp_seq=25 ttl=128 time=1.132 ms
>> ping: sendto: No route to host
>> 64 bytes from 192.168.1.3: icmp_seq=34 ttl=128 time=3003.569 ms
>> 64 bytes from 192.168.1.3: icmp_seq=35 ttl=128 time=2002.963 ms
>> 64 bytes from 192.168.1.3: icmp_seq=36 ttl=128 time=1002.208 ms
>> 64 bytes from 192.168.1.3: icmp_seq=37 ttl=128 time=1.454 ms
>> ^C
>> --- 192.168.1.3 ping statistics ---
>> 38 packets transmitted, 15 packets received, 60.5% packet loss
>> round-trip min/avg/max/stddev = 0.860/601.670/3003.569/880.104 ms
>>
>> and:
>>
>> ue1: link state changed to DOWN
>> ue1: link state changed to UP
>> ue1: link state changed to DOWN
>> ue1: link state changed to UP
>> ue1: link state changed to DOWN
>> ue1: link state changed to UP
>> ue1: link state changed to DOWN
>> ue1: link state changed to UP
>> ue1: link state changed to DOWN
>> ue1: link state changed to UP
>> ue1: link state changed to DOWN
>> ue1: link state changed to UP
>> ue1: link state changed to DOWN
>> ue1: link state changed to UP
>> ue1: link state changed to DOWN
>> ue1: link state changed to UP
>>
>> >> I downloaded again from above links and are the same as the last:
>> >>
>> >> valfenda# md5 if_axe*
>> >> MD5 (if_axe.c) = 388b7aa84f0d2471f8b144033103618b
>> >> MD5 (if_axe.c.original) = c528c7cb5eb964a792d4c14dfaed47cf
>> >> MD5 (if_axe.c.v1) = 388b7aa84f0d2471f8b144033103618b
>> >> MD5 (if_axereg.h) = 10f85490cab59b8e40de261fd7ad81a5
>> >> MD5 (if_axereg.h.original) = 46f37d0f02a3c09463ceec58b743c6ce
>> >> MD5 (if_axereg.h.v1) = 10f85490cab59b8e40de261fd7ad81a5
>> >>
>> >> .original are files from 8-stable (via csup)
>> >> .v1 are the files from http://people.freebsd.org/~yongari/axe/
>> >> downloaded
>> >> when the fist test using those files were made.
>> >> regular .c files were downloaded now when I read this mail.
>> >>
>> >> did you uploaded some new version in
>> >> http://people.freebsd.org/~yongari/axe/ ? or I didn't got it ? :)
>> >>
>> >
>> > Oops, it seems I forgot to upload it after modifying it.
>> > Please download again. MD5 should be
>> > 507a672946e7c0394e83c79d1a12c9b5 (if_axe.c) and
>> > 10f85490cab59b8e40de261fd7ad81a5 (if_axereg.h)
>> >
>> >> should this modified version be a good test to fast ethernet axe nics
>> ?
>> >> my
>> >> linksys USB200M failed when in bridge after some time of use :( same
>> >
>> > Yes, the change made in if_axe.c is for AX88178, AX88772 and
>> > AX8872A. The change has no effect for AX88172. Your controller would
>> > be either AX88772 or AX88772A so chances are good to see different
>> > behavior than ever before.
>>
>> I have no idea on how to see this ... is there anyway ?
>>
>
> From the output you posted:
> axe0: <vendor 0x13b1 product 0x0018, rev 2.00/0.01, addr 2> on usbus2
> axe0: PHYADDR 0xe0:0x10
> product is 0x0018 which means Cisco USB200M V2 and its controller
> is AX88772A.
great :)
>> >> hardware I'm testing now. and the nics are ok, tested in OpenBSD with
>> >> same
>> >> hardware and same bridge and same pf conf file.
>> >>
>> >> thanks,
>> >>
>> >> matheus
>>
>> by the way, you would not know if an interrupt storm on the irq of the
>> fast ethernet axe would have anything to do with its driver, right ? it
>> just happens when in bridge mode (I figured out why the bridge was
>> stopping working - the other nic keeps working fine).
>>
>
> Normally bridge mode will put the controller into promiscuous mode.
> If there is a bug in setting promiscuous mode, you should have seen
> it whenever you use tcpdump on that interface. So if you run
> tcpdump on that interface, do you see interrupt storm?
> If you don't, it would be different issue, I guess.
I'm trying this, usb nic out of bridge, its own IP, tcpdump and iperf. few
minutes and no problem so far. let's see in some time. when bridging for
my DSL, it got something around 1~3Mbps of traffic. and in less then a
night (8 hours) the usb nic would say goodbye ...
thanks again,
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg.usb
Type: application/octet-stream
Size: 15989 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20101119/9e282c36/dmesg.obj
More information about the freebsd-usb
mailing list