|
Hi List,
We are running multiple LVS directors in a master/backup configuration using
keepalived. The directors are running an SMP kernel (2.4.32) on dual CPU
servers.
All services are LVS-DR. ipvs_syncmaster/ipvs_syncbackup are also running on
both
directors.
Occasionally the following message is logged, followed immediately by a kernel
panic.
IPVS: ip_vs_conn_hash(): request for already hashed, called from f8b69acf
I note this problem is similar to the one described at
http://archive.linuxvirtualserver.org/html/lvs-users/2005-03/msg00239.html
Although the patch listed in the above URL appears to be included in kernel
2.4.32.
Reading some of the posts in the archives, it is suggested that there may be
race conditions in LVS that can lead to kernel panics.
Is it worth switching to a non-SMP kernel?
I'm willing to apply kernel patches if any of the kernel developers on this
list want to explore this problem further.
Output from ksymoops:
Unable to handle kernel NULL pointer dereference at virtual address 00000004
f8b681f1
*pde = 284aa001
Oops: 0002
CPU: 1
EIP: 0010:[<f8b681f1>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 00000000 ebx: c61c5b20 ecx: 000058fa edx: 00000000
esi: f8b69960 edi: 00000020 ebp: 00000001 esp: f7ffbeb4
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=f7ffb000)
Stack: 00000000 2304ac83 00000000 c61c5b20 f8b69993 c61c5b20 00000001 c281ce60
00000400 00000282 c02aeb84 00000001 00000282 00000001 00000000 c01293c6
c61c5b20 c01297bf c61c5b20 c281cee0 d67ca840 dcceb780 00000001 00000000
Call Trace: [<f8b69993>] [<c01293c6>] [<c01297bf>] [<c0125295>]
[<c0125137>]
[<c0124ef9>] [<c010b10b>] [<c0107020>] [<c010da38>] [<c0107020>]
[<c010704c>]
[<c01070e2>] [<c01202a5>] [<c0120512>]
Code: 89 50 04 89 02 0f b7 43 40 c7 03 00 00 00 00 c7 43 04 00 00
>>EIP; f8b681f1 <[ip_vs]ip_vs_conn_unhash+51/a0> <=====
>>ebx; c61c5b20 <_end+5e478a8/3848ede8>
>>esi; f8b69960 <[ip_vs]ip_vs_conn_expire+0/190>
>>esp; f7ffbeb4 <_end+37c7dc3c/3848ede8>
Trace; f8b69993 <[ip_vs]ip_vs_conn_expire+33/190>
Trace; c01293c6 <update_wall_time+16/40>
Trace; c01297bf <timer_bh+1af/3d0>
Trace; c0125295 <bh_action+55/80>
Trace; c0125137 <tasklet_hi_action+67/a0>
Trace; c0124ef9 <do_softirq+d9/e0>
Trace; c010b10b <do_IRQ+fb/130>
Trace; c0107020 <default_idle+0/50>
Trace; c010da38 <call_do_IRQ+5/d>
Trace; c0107020 <default_idle+0/50>
Trace; c010704c <default_idle+2c/50>
Trace; c01070e2 <cpu_idle+52/70>
Trace; c01202a5 <call_console_drivers+65/120>
Trace; c0120512 <printk+142/180>
Code; f8b681f1 <[ip_vs]ip_vs_conn_unhash+51/a0>
00000000 <_EIP>:
Code; f8b681f1 <[ip_vs]ip_vs_conn_unhash+51/a0> <=====
0: 89 50 04 mov %edx,0x4(%eax) <=====
Code; f8b681f4 <[ip_vs]ip_vs_conn_unhash+54/a0>
3: 89 02 mov %eax,(%edx)
Code; f8b681f6 <[ip_vs]ip_vs_conn_unhash+56/a0>
5: 0f b7 43 40 movzwl 0x40(%ebx),%eax
Code; f8b681fa <[ip_vs]ip_vs_conn_unhash+5a/a0>
9: c7 03 00 00 00 00 movl $0x0,(%ebx)
Code; f8b68200 <[ip_vs]ip_vs_conn_unhash+60/a0>
f: c7 43 04 00 00 00 00 movl $0x0,0x4(%ebx)
<0>Kernel panic: Aiee, killing interrupt handler!
|
