Re: [ECOS] Re: DEBUG: Circular MBUF

[Nick Garnett <nickg at ecoscentric dot com>]

"Kevin S. Martin" <ksmartin1@sbcglobal.net> writes:

> > 
> > Hi,
> > 
> > Could you try another experiment?
> > 
> > Under unix, logged in as root, type this command:
> > 
> > ping -s 1000 -f YOUR_ECOS_BOARDS_IP
> > 
> > This will send 1000 byte packets to your eCOS board as fast as
> > your unix box will send them. For me, that would *always* kill
> > the board and cause it to lockup.  We gave up entirely on eCos
> > because of it's IP stack unreliability.
> > 
> > My personal belief is that, under heavy loads, eCos' TCP/IP stack
> > experiences a memory leak but we never traced it down, which is why
> > we gave up on it.

This is not the case. Part of my standard testing of eCos ethernet
drivers is to run exactly the sort of flood pings you describe
overnight, and often for much longer. With a correctly written driver
this will run indefinitely.

For example, with eCos running on a 400MHz PII with an i82559 ethernet
controller:

# time ping -f -s 3000 -c 200000 10.0.0.201
PING 10.0.0.201 (10.0.0.201) 3000(3028) bytes of data.
 
--- 10.0.0.201 ping statistics ---
200000 packets transmitted, 200000 received, 0% packet loss, time 273169ms
rtt min/avg/max/mdev = 1.041/1.261/11.105/0.100 ms, ipg/ewma 1.365/1.276 ms

real    4m33.185s
user    0m4.310s
sys     0m10.101s


No packet losses, no messages from eCos. 


> DEBUG: Circular MBUF 0x004d1280!
> DEBUG: Circular MBUF 0x004d1480!
> DEBUG: Circular MBUF 0x004d1280!

The only time I have ever seen symptoms like this is when an ethernet
driver is buggy and is handing completed transmission buffers back to
the upper levels more than once. There may be other driver bugs that
may give the same results.

So, what ethernet device are you using? It there anything unusual
about your platform? Is it a standard PC? Have you tried building eCos
with assertions enabled?

> I did some experimenting and found the exact size that the ping fails
> on:
> 
> ping -s 1472 MY_ECOS_BOARDS_IP  -> this work fine
> ping -s 1473 MY_ECOS_BOARDS_IP  -> this fails immediately
>

This is the point at which IP starts to fragment the packet. Perhaps
the problem is with handling the arrival of two packets in quick
succession, or maybe transmission of the reply. Maybe events are
getting lost somehow.

Take a look at the top of the device driver source, or maybe in its
header file, there should be a #define DEBUG you can enable to get
it to generate some trace messages. This might give you an idea about
what is happening.

> 
> Once in a while I get a slightly different symptom:
> 

> ASSERT FAIL: <3>support.c[124]cyg_panic() eth_drv_send: no header mbuf
> ASSERT FAIL: <3>support.c           [ 124] cyg_panic()
>

This seems to confirm that the mbuf pool is getting corrupted,
probably by the driver.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss