Re: CFT: vr(4)

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<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
 > 

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