Re: kernel panic - ip_vs_conn_hash(): request for already hashed

To: " users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: kernel panic - ip_vs_conn_hash(): request for already hashed
From: Horms <horms@xxxxxxxxxxxx>
Date: Fri, 23 Jun 2006 18:00:55 +0900 (JST)
In article <Pine.LNX.4.64.0606231050570.864@xxxxxxxxxxxxxxxxx> you wrote:
> 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
> 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.

Hi Con,

It sounds entirely likely that there is a race in there somewhere,
though its probably going to be quite hard to find exactly why
an entry is being hashed that is already hashed. I'll poke around
myself, but if anyone else wants to do likewise, please do.

In the mean time, a non-SMP kernel would be an excellent way to go.
Firstly, it may well eliminate the problem, or conversely show us that
its not an SMP locking issue. And secondly, if your box is primarly an
Linux Directory, it will probably perform slightly better with non-SMP
than SMP.


<Prev in Thread] Current Thread [Next in Thread>