recent CARP 'fixes'

2006-03-21 Thread Pete Vickers

Hi,

I have a pair of openbsd amd64 3.8+ boxes with a few shared carp  
interfaces. They were playing perfectly together until today. I  
upgraded one to the 20-03-06 snapshot ( the other is still at circa.  
18-12-2005). Now both the boxes claim to be carp MASTERs, with  
obvious consequences.


net.inet.carp.log=1 or tcpdump don't show any problems though.

/plus39.html lists 2 carp fixes. The first releates to HMAC calc, so  
I disabled the carp password, without any effect. The other fix  
relates to a 'short' incorrect MASTER status at boot - where as mine  
seems to persist indefinitely.


Is this an incompatability between o/s versions, or just a passing - 
current hiccup ?



/Pete


[EMAIL PROTECTED] /root cat /var/run/dmesg.boot
OpenBSD 3.9-current (GENERIC.MP) #750: Sun Mar 19 18:25:28 MST 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/ 
GENERIC.MP

real mem = 2146140160 (2095840K)
avail mem = 1834962944 (1791956K)
using 22937 buffers containing 214822912 bytes (209788K) of memory
mainbus0 (root)
ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca2/2 spacing 1
mainbus0: scanning 0x98800 to 0x98bf0 for MP signature
mainbus0: scanning 0x98400 to 0x987f0 for MP signature
mainbus0: scanning 0xf to 0x0 for MP signature
mainbus0: MP floating pointer found in bios at 0xf72f0
mainbus0: MP config table at 0x9bb20, 372 bytes long
mainbus0: Intel MP Specification (Version 1.4) (AMD  HAMMER  )
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Opteron(tm) Processor 252, 2612.34 MHz
cpu0:  
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, 
CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB  
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully  
associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully  
associative

cpu0: calibrating local timer
cpu0: apic clock running at 200MHz
cpu0: kstack at 0x800067d66000 for 20480 bytes
cpu0: idle pcb at 0x800067d66000, idle sp at 0x800067d6aff0
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Opteron(tm) Processor 252, 2612.04 MHz
cpu1:  
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, 
CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB  
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully  
associative
cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully  
associative

cpu1: kstack at 0x800067d6b000 for 20480 bytes
cpu1: idle pcb at 0x800067d6b000, idle sp at 0x800067d6fff0
mpbios: bus 0 is type PCI
mpbios: bus 1 is type PCI
mpbios: bus 2 is type PCI
mpbios: bus 3 is type PCI
mpbios: bus 4 is type PCI
mpbios: bus 128 is type PCI
mpbios: bus 129 is type PCI
mpbios: bus 134 is type PCI
mpbios: bus 139 is type ISA
ioapic0 at mainbus0 apid 2 pa 0xfec0, virtual wire mode, version  
11, 24 pins
ioapic1 at mainbus0 apid 3 pa 0xd800, virtual wire mode, version  
11, 7 pins
ioapic2 at mainbus0 apid 4 pa 0xd8001000, virtual wire mode, version  
11, 7 pins

ioapic0: int0 attached to ExtINT (type 0x3 flags 0x5)
ioapic0: int1 attached to isa0 irq 1 (type 0x0 flags 0x5)
ioapic0: int2 attached to isa0 irq 2 (type 0x0 flags 0x5)
ioapic0: int3 attached to isa0 irq 3 (type 0x0 flags 0x5)
ioapic0: int4 attached to isa0 irq 4 (type 0x0 flags 0x5)
ioapic0: int5 attached to isa0 irq 5 (type 0x0 flags 0x5)
ioapic0: int6 attached to isa0 irq 6 (type 0x0 flags 0x5)
ioapic0: int7 attached to isa0 irq 7 (type 0x0 flags 0x5)
ioapic0: int8 attached to isa0 irq 8 (type 0x0 flags 0x5)
ioapic0: int9 attached to isa0 irq 9 (type 0x0 flags 0x5)
ioapic0: int10 attached to isa0 irq 10 (type 0x0 flags 0xf)
ioapic0: int11 attached to isa0 irq 11 (type 0x0 flags 0xf)
ioapic0: int12 attached to isa0 irq 12 (type 0x0 flags 0x5)
ioapic0: int13 attached to isa0 irq 13 (type 0x0 flags 0x5)
ioapic0: int14 attached to isa0 irq 14 (type 0x0 flags 0x5)
ioapic0: int15 attached to isa0 irq 15 (type 0x0 flags 0x5)
ioapic0: int10 attached to pci0 device 2 INT_A (type 0x0 flags 0xf)
ioapic0: int11 attached to pci0 device 2 INT_B (type 0x0 flags 0xf)
ioapic0: int10 attached to pci0 device 8 INT_A (type 0x0 flags 0xf)
ioapic0: int11 attached to pci1 device 5 INT_A (type 0x0 flags 0xf)
ioapic0: int11 attached to pci2 device 0 INT_A (type 0x0 flags 0xf)
ioapic0: int10 attached to pci3 device 0 INT_A (type 0x0 flags 0xf)
local apic: int0 attached to ExtINT (type 0x3 flags 0x5)
local apic: int1 attached to NMI (type 0x1 flags 0x5)
mainbus0: MP WARNING: 160 bytes of extended entries not examined
pci0 at mainbus0 bus 0: configuration mode 1
NVIDIA nForce4 DDR rev 0xa3 at pci0 dev 0 function 0 not configured
pcib0 at pci0 dev 1 function 0 NVIDIA nForce4 ISA rev 0xa3
nviic0 at pci0 dev 1 function 1 NVIDIA nForce4 SMBus rev 0xa2
iic0 at 

Re: recent CARP 'fixes'

2006-03-21 Thread Daniel Ouellet

Pete Vickers wrote:

Hi,

I have a pair of openbsd amd64 3.8+ boxes with a few shared carp 
interfaces. They were playing perfectly together until today. I upgraded 
one to the 20-03-06 snapshot ( the other is still at circa. 18-12-2005). 
Now both the boxes claim to be carp MASTERs, with obvious consequences.


net.inet.carp.log=1 or tcpdump don't show any problems though.

/plus39.html lists 2 carp fixes. The first releates to HMAC calc, so I 
disabled the carp password, without any effect. The other fix relates to 
a 'short' incorrect MASTER status at boot - where as mine seems to 
persist indefinitely.


Is this an incompatability between o/s versions, or just a passing 
-current hiccup ?


There is/was an issue between the two version:

http://marc.theaimsgroup.com/?l=openbsd-miscm=113790376714674w=2

Look to me that you run a snapshot that still have the issue in it, your 
 18-12-2005 one. I would upgrade that one to first as I know there was 
a problem then I point it out and that got fix quickly as well.


Daniel



Re: recent CARP 'fixes'

2006-03-21 Thread Daniel Ouellet

Pete Vickers wrote:
Is this an incompatability between o/s versions, or just a passing 
-current hiccup ?


Here is the patch that fixed it then.

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip_carp.c.diff?r1=1.118r2=1.119

Daniel