Date: Wed, 27 Feb 2008 12:09:42 -0500 From: Mike Tancsa <mike@sentex.net> To: pyunyh@gmail.com Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) Message-ID: <200802271712.m1RHC6Rx060293@lava.sentex.ca> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=b<RXCSUM,TXCSUM,VLAN_MTU>
ether 00:00:24:c9:34:8a
inet 192.168.7.21 netmask 0xffffff00 broadcast 192.168.7.255
media: Ethernet autoselect (100baseTX <full-duplex>)
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802271712.m1RHC6Rx060293>