Network freeze out of clusters

[Smith, Gene]

I had *big* problems with this, during flood pings, or heavy network traffic
or lots of 
connects/disconnect or cable on/off abuse. After I got my application fixed
(the same task that was trying to get clusters also needed to free them -
split into two tasks) I could still get the "waiting for mbuf cluster"
message but it would stop after about 4.5 minutes and things would start
working again. I got rid of this problem by changing rtems_glue.c,
m_clalloc() to wait a maximum of 1 second for clusters to free up instead of
forever. Had to also allow the ethernet driver to drop the packet if it
could not get a cluster in call to MGETCL (m->m_ext.ext_buf == NULL implies
no available cluster). It's still bad to wait a second in an isr, but its
better than a system lock-up!
-gene

>-----Original Message-----
>From: suvrat gupta [mailto:suvrat at utstar.com]
>Sent: Wednesday, August 08, 2001 6:43 PM
>To: Rtems-Users
>Subject: Network freeze out of clusters
>
>
>Hi,
>I am using RTEMS 4.5.0. There is some problem with the IP 
>task. If I pump enough data
>at the card I end up getting "Still waiting for an mbuf 
>cluster" message. The only way
>out is a reboot.
>I am NOT running any appplication task which opens or closes 
>sockets. I am pumping
>data by ping or by sending TCP connect request(which are 
>rejected since there is no
>application listening on that TCP socket).
>Has anyone seen similar problems? I am aware of the network 
>freeze problem caused by
>improper handling of sockets by application tasks. This is a 
>different problem.
>Any insights will be helpful.
>thanks
>-suvrat
>
>