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

[Mario Ramos <mario.ramos@xxxxxxxxxxxxxxxxxx>]

Since I installed linux virtual server, for some reason every now and 
again (once or twice a month) I was getting kernel panics.
I read somewhere to disable

Enable kernel irq balancing

Everythings fine since then.
It may not have anything to do with your problem or linux virtual server 
but it works for me with kernel 2.6.10 since I changed that.
Regards.
Mario.


Horms wrote:
> 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
> > 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.
> >     
> 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.
>
>