From owner-freebsd-current@FreeBSD.ORG Wed Feb 27 17:12:08 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 276C21065671 for ; Wed, 27 Feb 2008 17:12:08 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 06E1B8FC2A for ; Wed, 27 Feb 2008 17:12:07 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m1RHC7Rv022623; Wed, 27 Feb 2008 12:12:07 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m1RHC6Rx060293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2008 12:12:06 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200802271712.m1RHC6Rx060293@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Feb 2008 12:09:42 -0500 To: pyunyh@gmail.com From: Mike Tancsa In-Reply-To: <20080226053423.GB47750@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) 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: Wed, 27 Feb 2008 17:12:08 -0000 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 ---Mike