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

[Pyun YongHyeon]

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

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