usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic

Fri Nov 19 19:27:36 UTC 2010

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.

>  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.

> >> 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.