Date: Thu, 18 Nov 2010 21:12:13 -0200 From: "Nenhum_de_Nos" <matheus@eternamente.info> To: pyunyh@gmail.com Cc: freebsd-usb@freebsd.org Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic Message-ID: <bab43754fb4c3361ef0d990af3c3bd07.squirrel@eternamente.info> In-Reply-To: <20101118202426.GB8512@michelle.cdnetworks.com> References: <201011181510.oAIFA7SZ034209@freefall.freebsd.org> <833a33ce5369c53c6db220b79e379092.squirrel@eternamente.info> <20101118202426.GB8512@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@gmail.com> >> > To: bug-followup@FreeBSD.org, sub.mesa@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 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). 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bab43754fb4c3361ef0d990af3c3bd07.squirrel>