Hi Ramesh, We are using chariot and iperf tools to pump traffic. >Also which ethernet driver are you using? I'm using marvell switch driver on Openwrt. >but we used bonding driver which wasn't allocating enough memory for some fragments causing a leak and subsequently a >panic at a later stage. Although we are not using bonding driver, but my case is similar to yours, i.e. skbuff_head_cache goes on increasing and at threshold value, kernel crashes. >You might want to try dumping & match the allocated size for each skb & match with the corresponding free. Do you mean to use printk or is there any other way for dumping??? Thanks, Sharad. -----Original Message----- From: Ramesh [mailto:rramesh1@xxxxxxxxx] Sent: Tuesday, April 14, 2009 12:01 AM To: Tekale Sharad-FHJN78 Cc: kernelnewbies@xxxxxxxxxxxx Subject: Re: Out of memory + skbuff_head_cache Tekale Sharad-FHJN78 wrote: > Hi, > > I'm using linux 2.6.21.5 and our kernel is freeze. > > The problem I'm facing is, when I create a software bridge using > *$brctl* command. and add two interfaces say, eth0.0 and eth0.1, this > way... > > $brctl addbr br-lan > $brctl addif br-lan eth0.0 > $brctl addif br-lan eth0.1 > > When I send traffic from a host connected to one port to host > connected at other at or above end 60Mbits/sec , soon all the *memory > is dried up/consumed and and system crashes.* > > Observation: > On initial start up: > $cat /proc/slabinfo | grep skbuff_head_cache > skbuff_head_cache 120 120 192 20 1 : tunables 120 > 60 0 : slabdata 6 > > Before crash: > $cat /proc/slabinfo | grep skbuff_head_cache > skbuff_head_cache 4260 4260 192 20 1 : tunables 120 > 60 0 : slabdata 213 213 0 > > Can any one help me to refer to some patch or point to some location > in code from where memory is failed to deallocate. > > Thanks, > Sharad. Hello Sharad, What type of packets & packet sizes are you sending ? Also which ethernet driver are you using? In a problem what I faced before, we had a similar situation, but we used bonding driver which wasnt allocating enough memory for some fragments causing a leak and subsequently a panic at a later stage. You might want to try dumping & match the allocated size for each skb & match with the corresponding free. Regards Ramesh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
