From owner-freebsd-usb@FreeBSD.ORG Fri Nov 19 00:40:17 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57E001065672 for ; Fri, 19 Nov 2010 00:40:17 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 1C4338FC12 for ; Fri, 19 Nov 2010 00:40:16 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id D868A1CC3E; Thu, 18 Nov 2010 21:40:10 -0300 (BRT) Received: from 187.114.198.138 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Thu, 18 Nov 2010 22:40:10 -0200 Message-ID: <32aed4c0a483f26c662dd513ea718a78.squirrel@eternamente.info> In-Reply-To: <20101119000618.GC8512@michelle.cdnetworks.com> References: <201011181510.oAIFA7SZ034209@freefall.freebsd.org> <833a33ce5369c53c6db220b79e379092.squirrel@eternamente.info> <20101118202426.GB8512@michelle.cdnetworks.com> <20101119000618.GC8512@michelle.cdnetworks.com> Date: Thu, 18 Nov 2010 22:40:10 -0200 From: "Nenhum_de_Nos" To: pyunyh@gmail.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-usb@freebsd.org Subject: Re: usb/140883: [axe] [usb8] USB gigabit ethernet hangs after short period of traffic X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 00:40:17 -0000 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 >> >> > 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: at usbus2 >> axe1: on usbus2 >> axe1: PHYADDR 0xe0:0x01 >> miibus2: on axe1 >> ukphy2: 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 >> ue1: 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: 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. sorry, forgot to add: uname -a FreeBSD valfenda.apartnet 8.1-STABLE FreeBSD 8.1-STABLE #2: Fri Nov 5 01:52:06 BRT 2010 root@valfenda.apartnet:/usr/obj/usr/src/sys/valfenda i386 and this is using that axe(4) you posted :) just got a little deeper, and put two of them (all I have) connected. when in 1000Base-TX FullDuplex, the throughput is horrible., never get more then 3% of the link (on side this FreeBSD Stable shown above, the other Win7 and belkin drivers for it). when I force for 100BaseTX FullDuplex on Windows, and this way I get 68Mbps out of it (need to say the windows task manager keeps showing 90% link utilization quite all time, some falls from time to time though). thanks as usual, matheus >> 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 > -- 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