From owner-freebsd-current@FreeBSD.ORG Thu Feb 28 00:30:35 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 5B22E1065670 for ; Thu, 28 Feb 2008 00:30:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id 1BACE8FC19 for ; Thu, 28 Feb 2008 00:30:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so2719649wfa.7 for ; Wed, 27 Feb 2008 16:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=H5kTFzqcGnLF0hASRr/UI2HfzBaBjiSbg4ACZG6vM08=; b=OSgaC295mPDGFCtbfaIi83D3JExy3iSsAjYRfZI+0Fza+w+BbmdOjyauM0id8H//+n3wRGLL2CD2W3Ewl3KsJj4GJnTNIqIwCHd+8jy+DjnNUDtFOVITq6+m+P4gjtew+EBv13FofIXxvBbARojmjKQBm0FWuQuB8h1F1cA3SSQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=GxZq5WCUBYiLNMYrL/t0rMZ9eJMmrI9ryGrKksTNJ/Wwjj2xAy4Qd05PIt9hCIE3ovpQOpFhYg0L3E9Y3qHbHxULTXjKeFs2mRbWAXEW89QudcCqPW6pziuiXgqFEEGUFCYcSeWeoQCRmKp81zV8pMyj87C94I8ztb7tiaz8XyA= Received: by 10.142.52.9 with SMTP id z9mr5924238wfz.201.1204158634729; Wed, 27 Feb 2008 16:30:34 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 24sm15762405wfc.18.2008.02.27.16.30.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Feb 2008 16:30:33 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m1S0USCj056651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2008 09:30:28 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m1S0URp5056650; Thu, 28 Feb 2008 09:30:27 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 28 Feb 2008 09:30:27 +0900 From: Pyun YongHyeon To: Mike Tancsa Message-ID: <20080228003027.GA56411@cdnetworks.co.kr> References: <20080204022334.GC27999@cdnetworks.co.kr> <20080217112104.X80805@fledge.watson.org> <200802171458.26951.freebsd-current@dino.sk> <200802171517.26965.freebsd-current@dino.sk> <20080218081801.GB14601@cdnetworks.co.kr> <20080222054356.GE30497@cdnetworks.co.kr> <200802260503.m1Q53Jm3050738@lava.sentex.ca> <20080226053423.GB47750@cdnetworks.co.kr> <200802271712.m1RHC6Rx060293@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802271712.m1RHC6Rx060293@lava.sentex.ca> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 00:30:35 -0000 On Wed, Feb 27, 2008 at 12:09:42PM -0500, Mike Tancsa wrote: > At 12:34 AM 2/26/2008, Pyun YongHyeon wrote: > > > > > > >Thanks again for your testing! > >An unresolved issue for Milan Obuch's router board still prevent me > >from committing the overhauled one. Unfortunately I still have no > >clue why his hardware does not work even though it has the same > >hardware revision(0x96). > > I found another bug that your version of the driver fixes. Its > fairly easy for me to reproduce now and other people seem to run into > it as well. > > I hooked up 2 boxes with the NICs to a cisco switch with the 2 > interfaces on the same vlan. I then start a continuous ping either > from the other box, or on the box itself. > > boxA# ping boxB > PING 192.168.7.23 (192.168.7.23): 56 data bytes > 64 bytes from 192.168.7.23: icmp_seq=0 ttl=64 time=0.974 ms > 64 bytes from 192.168.7.23: icmp_seq=1 ttl=64 time=0.420 ms > 64 bytes from 192.168.7.23: icmp_seq=2 ttl=64 time=0.427 ms > 64 bytes from 192.168.7.23: icmp_seq=3 ttl=64 time=0.416 ms > 64 bytes from 192.168.7.23: icmp_seq=4 ttl=64 time=0.455 ms > 64 bytes from 192.168.7.23: icmp_seq=5 ttl=64 time=0.405 ms > 64 bytes from 192.168.7.23: icmp_seq=6 ttl=64 time=0.423 ms > 64 bytes from 192.168.7.23: icmp_seq=7 ttl=64 time=0.422 ms > > > ^C > --- 192.168.7.23 ping statistics --- > 66 packets transmitted, 20 packets received, 69.7% packet loss > round-trip min/avg/max/stddev = 0.396/0.476/0.974/0.132 ms > > > While in the middle of the ping, I change the media speed of the port > of the box that is doing the pinging to 10 and then back to auto > boxA# ifconfig vr2 > vr2: flags=8843 metric 0 mtu 1500 > options=b > ether 00:00:24:c9:34:8a > inet 192.168.7.21 netmask 0xffffff00 broadcast 192.168.7.255 > media: Ethernet autoselect (100baseTX ) > status: active > > The nic is now wedged on boxA. I then have to do a ifconfig vr2 down > and ifconfig vr2 up to un wedge it, and in the logs I see the forced reset > > vr2: link state changed to DOWN > vr2: link state changed to UP > vr2: link state changed to DOWN > vr2: link state changed to UP > vr2: Using force reset command. > > ..... HOWEVER, using the updated drivers on your web page, the box > survives this exercise. > > There is the occasional "shutdown error", but I guess thats to be > expected as the physical layer is bouncing up and down. But the main > thing is that the box recovers on its own. > > vr2: link state changed to DOWN > vr2: link state changed to UP > vr2: link state changed to DOWN > vr2: link state changed to UP > vr2: link state changed to DOWN > vr2: link state changed to UP > vr2: vr_link_task: Tx/Rx shutdown error -- resetting > vr2: link state changed to DOWN > vr2: restarting > vr2: vr_stop: Rx shutdown error > vr2: Using force reset command. > vr2: link state changed to UP > I never thought this kind of testing. It's good to hear vr(4) recovers from the abrupt link change events. I guess this also indicates the overhauled vr(4) can close lots of PR for vr(4). Thanks again. > ---Mike > -- Regards, Pyun YongHyeon