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

[Pyun YongHyeon]

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

> ue1: <USB Ethernet> on axe1
> ue1: Ethernet address: "my mac shown here :)"
> 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
> 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
> ugen1.2: <Microsoft> at usbus1 (disconnected)
> ukbd0: at uhub1, port 1, addr 2 (disconnected)
> ums0: at uhub1, port 1, addr 2 (disconnected)
> uhid0: at uhub1, port 1, addr 2 (disconnected)
> ue1: link state changed to DOWN
> ue1: link state changed to UP
> 
> the good thing is, it usually never got recognized, and was said not to
> have a PHY (or something alike).
> 

Are you using 8.1-RELEASE? If yes, please give it try stable/8 and
use axe(4) I posted.

> so I get this:
> 
>  ping 192.168.1.2
> PING 192.168.1.2 (192.168.1.2): 56 data bytes
> ping: sendto: No route to host
> 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.912 ms
> 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.842 ms
> ping: sendto: No route to host
> 64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=1.015 ms
> 64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=0.774 ms
> 64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=0.789 ms
> 64 bytes from 192.168.1.2: icmp_seq=9 ttl=64 time=0.851 ms
> 64 bytes from 192.168.1.2: icmp_seq=10 ttl=64 time=0.915 ms
> ^C
> --- 192.168.1.2 ping statistics ---
> 11 packets transmitted, 7 packets received, 36.4% packet loss
> round-trip min/avg/max/stddev = 0.774/0.871/1.015/0.077 ms
> 
> on local network.
> 
> 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