Thanks for your replying.
I have resolved that problem.
I found a bug in function *fcc_enet_start_xmit*.
In linux-2.6.12 and linux-2.6.9, the bug had been
patched by Dan Malek.
In fcc_net.c of linux-2.6.5,
at the end of *fcc_enet_start_xmit* :
if (bdp->cbd_sc & BD_ENET_TX_READY) {
netif_stop_queue(dev);
cep->tx_full = 1;
}
This cann't be used to decide TX-BD is full.
If the rate of transmit is too high, the *skbuf*
in TX-BD probably have not chance to be free befor
a new one had been put in. So, memory been lost.
> On Wed, 13 Jul 2005 10:42:52 +0800 (CST)
> gqbenjamin at 21cn.com wrote:
>
> > Hi,
> >
> > I use a device, like SMARTBITS, to test the Ethernet rate of mpc8250. The
> > kernel is linux-2.4.20
> > with CONFIG_FCC_LXT971 and CONFIG_USE_MDIO, and do 'cat
> > "1">/proc/sys/net/ipv4/ip_forward'.
> >
> > If the rate of sending IP packet been set too high, for example 100 Mbps
> > Full Duplex and each
> > packet is 1514 Bytes. Later, the kernel print '... Memory squeeze, dropping
> > packet' on uart. Stop
> > sending IP packet and do 'cat /proc/meminfo', the *MemFree* become small.
> >
> > Try again, the *MemFree* become smaller, just look like some allocated
> > memory (skbuf) do not be
> > free.
> >
> > Final, the kernel break down, because all memory have been used.
>
>
> It sounds to me like the problem may be that fcc_enet_rx() is consuming all
> the memory. This
> function is called in interrupt context and spins round the rx buffer
> descriptor ring until it finds
> an empty buffer descriptor. There is no check to stop it going round more
> than once and each time
> it finds a BD it does a dev_alloc_skb().
>
> It is possible that you are receiving data at a high enough rate that
> fcc_enet_rx() never exits.
>
> What is more likely is that there isn't enough time between rx interrupts for
> the CPU to tx all the
> queued packets.
>
>
> >
> > Q. How can I do to let kernel do not break down? Is it a kernel promblem?
> >
>
> This is just a guess, but... it may help to move fcc_enet_rx() from the
> interrupt handler to a
> bottom half. If you do this you should also ensure that it cannot process
> the rx buffer descriptor
> ring more than once per call. This may give the CPU *more* chance to tx
> queued packets by lowering
> the rx priority a little.
>
> I don't know if this would work but I'd be interested to find out.
>
> Alex
----------------------------------------------
vgo????????????????????????????
http://vgo.21cn.com
??????????????????4G??????
http://mail.21cn.com/huodong/0504/mail/
??????????????!????????!
http://qipai.g.21cn.com
??????????????????????
http://super.21cn.com/
??????????????????????????
http://y.21cn.com/club/
????????????????????????????
http://pas.21cn.com/
??????2005????????????
http://callme.21cn.com
