LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Unable to handle kernel NULL pointer dereference at virtual address

To: Ratz <ratz@xxxxxx>
Subject: Re: Unable to handle kernel NULL pointer dereference at virtual address
Cc: Joseph Mack <mack.joseph@xxxxxxx>, "lvs-users@xxxxxxxxxxxxxxxxxxxxxx" <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Wensong Zhang <wensong@xxxxxxxxxxxx>
Date: Wed, 26 Apr 2000 09:18:16 +0800 (CST)

Hi Ratz,

Sorry that the summary is not very correct.

If IP_VS_SVC_TAB_SIZE is set 17, the two static variables

/* the service table hashed by <protocol, addr, port> */
struct list_head ip_vs_svc_table[IP_VS_SVC_TAB_SIZE];
/* the service table hashed by fwmark */
struct list_head ip_vs_svc_fwm_table[IP_VS_SVC_TAB_SIZE];

will need 2M bytes (2^17*8*2), it doesn't reach your 64M bytes. Since they
are static variable allocated in the kernel image, it reachs the limit of
kernel image size.

I thought that there is often very few virtual service entry on a LVS box,
such as one or two, and service table of 256 first-layer entries are big
enough for most application, so I simply used the static variables.

BTW, do you really need such a big table of 128K (2^17) entries at first
layer?

Thanks,

Wensong


On Tue, 25 Apr 2000, Ratz wrote:

> Joseph Mack wrote:
> > 
> > Ratz wrote:
> > 
> > > I think I should compile the IP_VS_SVC_TAB_BITS with
> > > a smaller value, f.e to 12 instead of 17, because I've only
> > > got 64Mbytes in my machine :)
> > >
> > > If this was the reason, I apologize to everybody for this
> > > postings.
> > 
> > please don't apologize. If this is a problem and you have found the
> > cause, then it can be easily fixed.
> > 
> > Joe
> > 
> > --
> > Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
> > contractor to the National Environmental Supercomputer Center,
> > mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
> 
> Hi Joseph,
> 
> I just thought, that some readers here are not extremely interested
> in a kernel oops dump rather then in a solution for a problem like
> this. So I could have made deeper investigations before addressing
> a latent problem to the public. 
> Ok, actually, it seems that setting the value of IP_VS_SVC_TAB_BITS
> to a reasonable value fixes the problem, no oops since 2 hours. I'll
> have a look at this the next couple of days to see if I can reproduce
> the problem.
> 
> SUMMARY
> -------
> 
> 
> DESCRIPTION:
> 
> As far as I investigated the kernel seems to fault and print oops 
> messages if ( 2**IP_VS_SVC_TAB_BITS > amount_of_memory [in KBytes] )
> 
> SOLUTION:
> 
> Choose a value for IP_VS_SVC_TAB_BITS where:
> 2**IP_VS_SVC_TAB_BITS < amount_of_memory [in KBytes]
> 
> TELL-TALE
> 
> This problem is not approved nor really deep investigated. It is 
> just in case you'd encounter such strange kernel oops, then this
> could be the solution to your problem.
> 
> 



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