Re: Fw: linux Bridge: out of memory!!

[Sales <sales@etinc.com>]

We dont use the LINUX bridge code, we have our own.

At 02:33 AM 08/22/2003, zhongqx-local wrote:

>----- Original Message -----
>From: zhongqx-local
>To: dennis@etinc.com
>Cc: linuxppc-embedded@lists.linuxppc.org ; alan@lxorguk.ukuu.org.uk
>Sent: Friday, August 22, 2003 2:32 PM
>Subject: linux Bridge: out of memory!!
>
>
>Sir,
>     Read you problem from internet, I also meet the same problem with
> you, have you already
>solved the linux memory issue with net bridge ? if so can you tell me how
>to deal with it?
>thank you advanced !!!
>     what version of linux are you use? I can not use mark_bh(NET_BH)
> which NET_BH is not defined in the kernel 2.4.4.what is the instead the
> NET_BH in 2.4.4?
>
>     I describe the problem in the following:
>
>
>     I am developing a BRIDGE with in MPC860 and linux kernel 2.4.4(denx
> linux-2.4.4-2002-02-14).I make a bridge BR0 with eth1(100M FEC) and eth0
> (10M scc1),my total ram is 16M ,I used a 6M ramdisk.When I boot
>the kernel I find the free memory is about 5M,But when I ftp a large files
>through the bridge,I find that
>the free memory become fewer and fewer,at last the free memory is about
>500K ,then the kernel killed all process and restart itself like the following:
>
>
>#
># | STATE_BRID_I1: retransmission; will wait 10s for response time 1
>br0: port 2(eth1) entering learning state
>br0: port 1(eth0) entering learning state
>br0: received tcn bpdu on port 2(eth1)
>br0: topology change detected, propagating
>| STATE_BRID_I1: retransmission; will wait 10s for response time 2
>br0: port 2(eth1) entering forwarding state
>br0: topology change detected, propagating
>br0: port 1(eth0) entering forwarding state
>br0: topology change detected, propagating
>| it seens Center ID is illegal
>| STATE_BRID_I1: retransmission; will wait 10s for response time 3
>| add center 192.168.1.242 public key sucessly
>send work key to bridge c0a801f2
>total drop skb 1 packet!
>__alloc_pages: 0-order allocation failed.
>eth1: Memory squeeze, dropping packet.
>__alloc_pages: 0-order allocation failed.
>eth1: Memory squeeze, dropping packet.
>__alloc_pages: 0-order allocation failed.
>eth1: Memory squeeze, dropping packet.
>__alloc_pages: 0-order allocation failed.
>eth1: Memory squeeze, dropping packet.
>__alloc_pages: 0-order allocation failed.
>eth1: Memory squeeze, dropping packet.
>__alloc_pages: 0-order allocation failed.
>eth1: Memory squeeze, dropping packet.
>__alloc_pages: 0-order allocation failed.
>eth1: Memory squeeze, dropping packet.
>__alloc_pages: 0-order allocation failed.
>eth1: Memory squeeze, dropping packet.
>__alloc_pages: 0-order allocation failed.
>eth1: Memory squeeze, dropping packet.
>__alloc_pages: 0-order allocation failed.
>__alloc_pages: 0-order allocation failed.
>eth0: Memory squeeze, dropping packet.
>eth1: Memory squeeze, dropping packet.
>__alloc_pages: 0-order allocation failed.
>eth1: Memory squeeze, dropping packet.
>Out of Memory: Killed process 21 (sh).
>Terminated
>Out of Memory: Killed process 7 (linuxrc).
>
>The system is going down NOW !!
>Sending SIGTERM to all processes.
>klips_debug:pfkey_remove_socket: succeeded.
>klips_debug:pfkey_destroy_socket: destroyed.
>klips_debug:pfkey_release: succeeded.
>Sending SIGKILL to all processes.
>Please stand by while rebooting the system.
>Restarting syst
>
>PPCBoot 1.1.5 (Mar 26 2003 - 10:24:01)
>
>CPU:   XPC860xxZPnnD4 at 50.00 MHz: 4 kB I-Cache 4 kB D-Cache FEC present
>Board: Embedded Linux development kits for MPC8xx se
>ries...
>DRAM:  16 MB
>In:    serial
>Out:   serial
>Err:   serial
>
>'Type "run flash_nfs" to mount root filesystem over NFS'
>
>Hit any key to stop autoboot:  0
>BOOTP broadcast 1
>
>
>
>
>
>
>
>
>
>At 10:23 PM 09/07/2000 +0100, Alan Cox wrote:
> >> >Your explanation doesn't fit your observations. I suspect #2 may have
> some
> >> >significance but that would be unrelated to the rate of resource usage.
> >>
> >> Then why does inserting a "mark_bh" after a kfree_skb alleviate the
> problem
> >> somewhat? it certainly doesnt add to the performance.
> >
> >The mark_bh is already there. it sounds ot me like you are changing timing
> >patterns by causing a cpu stall on the memory bus
> >
>
>
>No, its not.
>
>
>I know you are busy, but it would be helpful if you actually read what I
>wrote before you answer.
>
>
>We have modifyed to ethernet driver to check the address before queuing the
>packet. There is virtually no overhead. Plus, when packets ARENT freed
>(such as when they are forwarded) a much more cpu intensive operation of
>cloning the packet and queuing it is done instead, and there are no
>problems doing > 100K pps. so its not causing any cpu stalls.
>
>
>
>Here's a test that even the college freshmen can understand:
>
>
>1) Set up a box with an eepro100 as a second card and modify the driver by
>simply replacing netif_rx() with kfree_skb(). My system is a 200Mhz Pentium
>
>
>skb->protocol.....
>kfree_skb(skb);
>sp->stats.rx_packets++
>yada, yada, yada....
>
>
>2) give the card an address with an ifconfig in rc.local
>3) wire the box to another box or hub/switch @ 100Mb/s
>4) setup a traffic generater on the wire and force the mac address to
>either broadcast or the mac address of the eepro card ie "arp -s
>207.11.14.1 ff:ff:ff:ff:ff:ff" so that the card will get the packets. You
>can check the rxpacket count with ifconfig to verify that the card is
>receiving the packets.
>5) fire packets at the eepro100 card...my test was about 4000pps.
>6) reboot the linux box
>
>
>virtually every time, the eepro driver will complain about "no resources"
>before the login prompt is displayed.
>
>
>7) now, modify the driver to include a mark_bh()
>
>
>skb->protocol.....
>kfree_skb(skb);
>mark_bh(NET_BH);
>sp->stats.rx_packets++
>yada, yada, yada....
>
>
>the complaints are noticably less.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/