From owner-freebsd-current@FreeBSD.ORG Tue Jan 22 19:35:30 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BE8B16A421 for ; Tue, 22 Jan 2008 19:35:30 +0000 (UTC) (envelope-from mailinglist@nesluop.dk) Received: from unixdunk.nesluop.dk (cpe.atm4-0-51450.0x535f05ca.hrnxx12.customer.tele.dk [83.95.5.202]) by mx1.freebsd.org (Postfix) with SMTP id 66BE913C478 for ; Tue, 22 Jan 2008 19:35:29 +0000 (UTC) (envelope-from mailinglist@nesluop.dk) Received: (qmail 91300 invoked by uid 89); 22 Jan 2008 19:28:45 -0000 Received: from unknown (HELO ?192.168.1.100?) (192.168.1.100) by unixdunk.nesluop.dk with SMTP; 22 Jan 2008 19:28:45 -0000 Message-ID: <479643EC.4000908@nesluop.dk> Date: Tue, 22 Jan 2008 20:28:44 +0100 From: Chris Poulsen User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20071225234723.GA1018@cdnetworks.co.kr> <4772D649.3010001@nesluop.dk> <20071227002252.GE1018@cdnetworks.co.kr> <20080116012154.GB84758@cdnetworks.co.kr> <478E7DF3.4080908@nesluop.dk> <20080117014013.GA89210@cdnetworks.co.kr> <478F98D7.5040007@nesluop.dk> <20080118010100.GC92718@cdnetworks.co.kr> <20080118082609.GA93423@cdnetworks.co.kr> <4790EBA8.9090500@nesluop.dk> <20080119060354.GA98043@cdnetworks.co.kr> In-Reply-To: <20080119060354.GA98043@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kevlo@freebsd.org, FreeBSD Current Subject: Re: Problem with nfe stability and throughput X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2008 19:35:30 -0000 Hi, I've had the chance to punish the atphy you suggested below (diff2 + suggested change). The driver seems slow (but "stable") when it is not being pushed (my ssh shell is lagging ;) and it seems to lock up within 10 secs (tried 3 times) when I try to perform a ftp transfer to the machine. By "lock-up" I see the network stops working. The ftp transfer stops, I'm unable to ping from the server and browsing the web from the machine also does not work. Manually doing ifconfig down/up brings the network back into a working state, I tried waiting a little to see if it recovered itself, but it didn't seem like it. So is there anything else I can do to help nailing this one? -- Regards Chris Pyun YongHyeon wrote: > On Fri, Jan 18, 2008 at 07:10:48PM +0100, Chris Poulsen wrote: > > Hi, > > > > Pyun YongHyeon wrote: > > >On Fri, Jan 18, 2008 at 10:01:00AM +0900, To Chris Poulsen wrote: > > > > On Thu, Jan 17, 2008 at 07:05:11PM +0100, Chris Poulsen wrote: > > > > > Hi, > > > > > > > > > > Pyun YongHyeon wrote: > > > > > >Would you show me the output of "ifconfig nfe0"? > > > > > > > > > > > nfe0: flags=8843 metric 0 > > > mtu 1500 > > > > > options=48 > > > > > ether 00:1d:60:6d:73:ec > > > > > inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 > > > > > media: Ethernet 100baseTX > > > > > status: active > > > > > > > > Hmmm, it seems that you've set media type manually without relying > > > > on automatic media detection. Is there any reason not using auto > > > > media type? How about using media type 'auto'? > > > > #ifconfig nfe0 media auto > > > > > > > > > >I've updated the experimental driver. Please revert previous patch and > > >apply the following one. > > > > > >http://people.freebsd.org/~yongari/atphy.diff2 > > > > > >And show me the 'ifconfig nfe0' output again. > > > > > > > I tried specifying the media type manually, when I was trying to get nfe > > up and running earlier, I've reverted to auto now. > > > > The box in question is currently running with your latest patch, I did > > manage to stress it (with a couple of concurrent ftp uploads+some web > > browing) into a state where it once again gave me a bunch of the following: > > > > kernel: nfe0: discard frame w/o leading ethernet header (len 4 pkt len 4) > > kernel: nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > > last message repeated 12 times > > kernel: nfe0: discard frame w/o leading ethernet header (len 3 pkt len 3) > > kernel: nfe0: discard frame w/o leading ethernet header (len 11 pkt len 11) > > kernel: nfe0: discard frame w/o leading ethernet header (len 5 pkt len 5) > > kernel: nfe0: discard frame w/o leading ethernet header (len 5 pkt len 5) > > kernel: nfe0: link state changed to DOWN > > kernel: nfe0: link state changed to UP > > > > However bringing the interface down and up seemed to put it back into a > > normal state. (I just noticed that nfe0 went down/up again, without my > > Did you have to bring nfe(4) down and up manually due to network lockups? > > > interaction, if that matters). > > > > Maybe this would come from atphy(4) bug. atphy(4) does not seem to > reliabily detect an established link. > > > ifconfig nfe0 yields: > > > > nfe0: flags=8843 metric 0 mtu 1500 > > options=48 > > ether 00:1d:60:6d:73:ec > > inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > How about the following change? > From /usr/src/sys/dev/mii/athpy.c: > 288 ssr = PHY_READ(sc, ATPHY_SSR); > 289 if ((((bmcr & BMCR_AUTOEN) != 0) && ((bmsr & BMSR_ACOMP) == 0)) || > 290 (ssr & ATPHY_SSR_SPD_DPLX_RESOLVED) == 0) { > 291 /* Erg, still trying, I guess... */ > 292 mii->mii_media_active |= IFM_NONE; > 293 return; > 294 } > > To: > 288 ssr = PHY_READ(sc, ATPHY_SSR); > 289 if ((ssr & ATPHY_SSR_SPD_DPLX_RESOLVED) == 0) { > 290 /* Erg, still trying, I guess... */ > 291 mii->mii_media_active |= IFM_NONE; > 292 return; > 293 } > > Thanks for your patience and testing. >