help: FCC_ENET OF MPC8250?

[gqbenjamin at 21cn.com]

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