[vortex] Problem with 3c905b under 2.2.16

[Andrew Morton]

Shane Wegner wrote:
> 
> > A fix for this went into Alan's 2.2.17-pre5 tree.  There's a copy at
> > http://www.uow.edu.au/~andrewm/linux/3c59x.c-2.2.17-pre5-1.gz - simply
> > replace the existing drivers/net/3c59x.c with that file and rebuild.
> 
> This seems to work though it still results in a temperary (about 15 second)
> outage after the data transmition is over.  Even to the point that processes
> can't execute.

mm..  The solution in this version of the driver was pretty crappy. 
When we've totally run out of rx buffers I use the transmit path to poll
to see if there is now memory available.  Consequently your Rx path
won't start working again until there is free memory and someone tries
to send something.  I used a 1 second timer for this in 2.4, which is a
better solution but involved more code changes.

> argus:~# ttcp -u -r
> ttcp-r: buflen=8192, nbuf=2048, align=16384/+0, port=5001  udp
> ttcp-r: socket
> 
> argus:~# clear
> su: fork: Cannot allocate memory
> argus:~# dmesg
> su: fork: Cannot allocate memory
> argus:~#
> 
> Wouldn't it be possible to just drop packets which it can't buffer rather
> than allocating to the end of ram?  Perhapse a configurable upper limit so
> user processes are not affected.

Well, it does drop the packets (what else could it do?) but yes, we've
totally run out of memory.

Should we leave some memory headroom?  Possibly.  But someone has to be
the one to run the system out of memory...

The netdev layer will buffer up to 300 incoming packets.  You can alter
this via /proc/sys/net/core/netdev_max_backlog, but I suspect you're
running out of memory at a higher level - 300 packets isn't much.


> PS. How much ram is required to run at 100mbps or is it the CPU and simply a
> question of time before the ram is exhausted.

The other entries in /proc/sys/net/core allow you to manipulate the size
of the per-socket queues, but I'm not sure where all your memory has
gone in this case.