cvs commit: src/sys/pci if_vr.c

[Pyun YongHyeon]

On Fri, Oct 26, 2007 at 10:35:44AM -0200, JoaoBR wrote:
 > On Friday 26 October 2007 10:18:32 Pyun YongHyeon wrote:
 > 
 > >  > >  > Hi
 > >  > >  > since I upgraded to 7 this days I loss connection to a machine with
 > >  > >  > vr nic
 > >  > >  >
 > >  > >  > the only event I can find after resetting (i have no phisical
 > >  > >  > access) is
 > >  > >  >
 > >  > >  > Oct 26 04:31:56 ap-c kernel: vr0: link state changed to DOWN
 > >  > >  >
 > >  > >  > may it be related? What should I do?
 > >  > >
 > >  > > I'm pretty sure it's not related with my changes.
 > >  > >
 > >  > > If you think vr(4) is culprit for the issue try overhauled vr(4).
 > >  > > I think I've fixed many unresolved vr(4) issues but it needs more
 > >  > > testing.
 > >  > > You can download the overhauled vr(4) at the following URL.
 > >  > > http://people.freebsd.org/~yongari/vr/if_vr.c
 > >  > > http://people.freebsd.org/~yongari/vr/if_vrreg.h
 > >  > >
 > >  > > Note, don't use the overhauled driver on your production system.
 > >  > > I couldn't see any issues in the driver but it may have unnoticed
 > >  > > bugs.
 > >  >
 > >  > I will arrange a test machine to see how it goes
 > >
 > > Ok. Let me know if you see any unusual things. Pluging/unpluging
 > > cables shouldn't affect the operation of vr(4). I heard stock vr(4)
 > > is vulerable to this type of link changes. In addition, you may
 > > notice better Rx performance.
 > >
 > 
 > oh no, it is not that, I wanted to say when the down event already has taken 
 > place then we can re-activate the vr nic (to up) by unplugging the network 
 > cable on the switch and access the machine again
 > 

There are two issues here. 1st, there should be no abnormal device
down and you shouldn't need to unplug/replug the cable to access the
machine. vr(4) should detect valid link automatically and reinitialize
it. 2nd, repeating cable plug/unplug action should not cause panic
anymore.

 > Also this machine is running almost a year perfectly releng_6 and current for 
 > over a month or so until the latest update 2 days ago
 > 

Probably not. I guess you missed one thing. phk changed a lot of code
to support checksum offload and rearranged the code a bit not to align
Tx buffers for Rhine II/III. These changes were not MFCed to RELENG_6.

 > btw, both files are almost twice in size, is it correct?
 > 
 > 66987 26 Out 10:27 if_vr.c
 > 39430 12 Out 00:41 if_vr.c.ori
 > 20062 26 Out 10:27 if_vrreg.h
 > 15445 23 Abr  2007 if_vrreg.h.ori
 > 
 > v 1.126 2007/04/23 12:19:02 phk
 > v 1.34 2007/04/23 12:19:02 phk
 > 

As I said in previous mail, it's major overhauled driver. It contains
all bus_dma(9) changes to run it on other architectures such as sparc64
and added new hardware feature support code.(VLAN hardware tag
insertion/extraction, CAM filtering support etc.)

-- 
Regards,
Pyun YongHyeon