Re: vr(4) diff

2010-12-11 Thread Thomas Pfaff
On Sat, 11 Dec 2010 00:41:00 +
Stuart Henderson s...@spacehopper.org wrote:

 On 2010/12/10 12:18, Brynet wrote:
  Mark Kettenis wrote:
   Here's an attempt to fix a potential MCLGETI issue with vr(4) similar
   to what I recently fixed fro re(4).  Unfortunately I don't have any
   vr(4) hardware myself, so I need some hep testing this.
   
 to replicate, on a fast nearby machine:
 
 pkg_add netrate
 netblast ip.addr.of.vr 1234 5 10
 
 i typically saw hangs in a fraction of a second on a vr/geode system.
 to recover connect in on another nic or the console and ifconfig vrX down
 then ifconfig vrX up.

No such problems here.  I did the netblast thing from an Intel Core
2 (see previous post for dmesg) and the vr(4) never stopped working,
with or without the patch.  During the blast it becomes completely
unresponsive over ssh and serial but I guess that's to be expected.



Re: vr(4) diff

2010-12-10 Thread Brynet
Mark Kettenis wrote:
 Here's an attempt to fix a potential MCLGETI issue with vr(4) similar
 to what I recently fixed fro re(4).  Unfortunately I don't have any
 vr(4) hardware myself, so I need some hep testing this.
 
 Things to look for are:
 
 1. Does this diff have any effect on throughput (packets/s, bits/s).
 
 2. Does this fix any problems with the interface if you blast it with
packets?
 
 3. Does livelock mitigation actualy work?
 
 Thanks,
 
 Mark

Hi Mark,

Did you receive any feedback for this? is there an easy way to replicate
the problems others are seeing, as my systems seem stable.

Using this patch doesn't seem to cause any noticeable performance
regressions.

-Bryan.



Re: vr(4) diff

2010-12-10 Thread Thomas Pfaff
Since you're wondering, here's my mail to Mark ...

(I've used vr(4) on my router for some time and installed another one
 on another system and I've never had any problems, though the traffic
 has been minimal).

On Fri, 10 Dec 2010 12:18:03 -0500
Brynet bry...@gmail.com wrote:

 Mark Kettenis wrote:
  Here's an attempt to fix a potential MCLGETI issue with vr(4) similar
  to what I recently fixed fro re(4).  Unfortunately I don't have any
  vr(4) hardware myself, so I need some hep testing this.
  
  Things to look for are:
  
  1. Does this diff have any effect on throughput (packets/s, bits/s).
  
  2. Does this fix any problems with the interface if you blast it with
 packets?
  
  3. Does livelock mitigation actualy work?
  
  Thanks,
  
  Mark
 
 Hi Mark,
 
 Did you receive any feedback for this? is there an easy way to replicate
 the problems others are seeing, as my systems seem stable.
 
 Using this patch doesn't seem to cause any noticeable performance
 regressions.
 

On Sun, 5 Dec 2010 16:44:27 +0100 (CET)
Mark Kettenis mark.kette...@xs4all.nl wrote:

 Here's an attempt to fix a potential MCLGETI issue with vr(4) similar
 to what I recently fixed fro re(4).  Unfortunately I don't have any
 vr(4) hardware myself, so I need some hep testing this.

No apparent problems here.  I get the same speed and no hangs, though I
never encountered hangs before.  I just installed this card.  I'm running
the December 4th snapshot.  Kernel sources from yesterday, ran with and
without your patch.

Not sure what blast it with packets mean, but I ran iperf and tcpbench
quite a while.  If you have other tools you want me to use, let me know.

Speed was stable at 94.2 Mbps, BTW.

$ dmesg | grep vr0
vr0 at pci0 dev 9 function 0 VIA VT6105 RhineIII rev 0x86: irq 5, address 
00:11:95:e2:bb:a1
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 4: OUI 0x004063, 
model 0x0034

$ ifconfig vr0
vr0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:11:95:e2:bb:a1
priority: 0
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 10.0.0.7 netmask 0xff00 broadcast 10.0.0.255
inet6 fe80::211:95ff:fee2:bba1%vr0 prefixlen 64 scopeid 0x2

# pcidump -v 0:9:0
 0:9:0: VIA VT6105 RhineIII
0x: Vendor ID: 1106 Product ID: 3106
0x0004: Command: 0117 Status ID: 2210
0x0008: Class: 02 Subclass: 00 Interface: 00 Revision: 86
0x000c: BIST: 00 Header Type: 00 Latency Timer: 40 Cache Line Size: 08
0x0010: BAR io addr: 0xd000/0x0100
0x0014: BAR mem 32bit addr: 0xcfffcf00/0x0100
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 1186 Product ID: 1403
0x0030: Expansion ROM Base Address: cffe
0x0038: 
0x003c: Interrupt Pin: 01 Line: 05 Min Gnt: 03 Max Lat: 08
0x0040: Capability 0x01: Power Management

$ dmesg
OpenBSD 4.8-current (GENERIC) #1: Mon Dec  6 16:34:47 CET 2010
tpf...@hack.tp76.info:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Athlon(tm) XP 1800+ (AuthenticAMD 686-class, 256KB L2 cache) 1.53 
GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real mem  = 267939840 (255MB)
avail mem = 253505536 (241MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 04/29/02, BIOS32 rev. 0 @ 0xfdae0, SMBIOS 
rev. 2.3 @ 0xf0630 (23 entries)
bios0: vendor American Megatrends Inc. version 07.00T date 04/02/01
bios0: ECS K7S5A
apm0 at bios0: Power Management spec V1.2
apm0: AC on, no battery
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf7950/160 (8 entries)
pcibios0: PCI Interrupt Router at 000:02:0 (SiS 85C503 System rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0xc000 0xcc000/0x8000
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 SiS 735 PCI rev 0x01
sisagp0 at pchb0
agp0 at sisagp0: aperture at 0xd000, size 0x200
ppb0 at pci0 dev 1 function 0 SiS 86C201 AGP rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 ATI Rage Pro rev 0x5c
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 2 function 0 SiS 85C503 System rev 0x00
ohci0 at pci0 dev 2 function 2 SiS 5597/5598 USB rev 0x07: irq 11, version 
1.0, legacy support
ohci1 at pci0 dev 2 function 3 SiS 5597/5598 USB rev 0x07: irq 12, version 
1.0, legacy support
pciide0 at pci0 dev 2 function 5 SiS 5513 EIDE rev 0xd0: 735: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: ST34321A
wd0: 32-sector PIO, LBA, 4103MB, 8404830 sectors

Re: vr(4) diff

2010-12-10 Thread Stuart Henderson
On 2010/12/10 12:18, Brynet wrote:
 Mark Kettenis wrote:
  Here's an attempt to fix a potential MCLGETI issue with vr(4) similar
  to what I recently fixed fro re(4).  Unfortunately I don't have any
  vr(4) hardware myself, so I need some hep testing this.
  
  Things to look for are:
  
  1. Does this diff have any effect on throughput (packets/s, bits/s).
  
  2. Does this fix any problems with the interface if you blast it with
 packets?
  
  3. Does livelock mitigation actualy work?
  
  Thanks,
  
  Mark
 
 Hi Mark,
 
 Did you receive any feedback for this? is there an easy way to replicate
 the problems others are seeing, as my systems seem stable.

i was hoping to have tested this already but i just had to burn the
couple of hours i had spare on getting some ipsec boxes to start
talking to each other again. maybe next week.

to replicate, on a fast nearby machine:

pkg_add netrate
netblast ip.addr.of.vr 1234 5 10

i typically saw hangs in a fraction of a second on a vr/geode system.
to recover connect in on another nic or the console and ifconfig vrX down
then ifconfig vrX up.