EEPRO Receiver Lock-up

[Kevin Dineley]

I found that, under conditions of high network and processor load, I
could lock-up the 82558 receiver.  It would not recover from this.

The reason seemed to be that the 82558 did not receive any new ring
buffers (dev_alloc_skb() failed 17 times).

My workaround was to allocate 'emergency_buf' in speedo_init_rx_ring().
If dev_alloc_skb() failed in the 'refill' of the ring buffers in
speedo_rx(), emergency_buf would be used instead.  Next time around,
speedo_rx() would check that emergency_buf==NULL, and instead of calling
netif_rx(), it would assign the received buffer back to emergency_buf,
effectively dropping the packet.   emergency_buf would then be available
for the next emergency refill.  This ensures that the 82558 always has
at least one buffer.

Can anyone comment on this?  Is buffer starvation the real cause of the
lock-up?  It may require some refinement, but would this method solve
it?