At 11:59 PM 09/05/2000 +0100, you wrote: >> calling mark_bh() after freeing the buffers seems to substantially lessen >> the condition (I assume this hastens some function which recaptures the >> freed buffers?) > >Yes. However mark_bh(NET_BH) is done for each packet queued anyway so that >doesnt make sense (netif_rx does it). no, these packets arent being queued...they are being dumped before being queued (why would you queue a packet that you know is bad?). Thats the issue. > >It might by an indication of this being timing issues, however until we can >get good databooks out of Intel who knows So, are you saying that there is no way to explicity free memory for immediate use? The issue with the eepro driver is that it doesnt recover even when the traffic subsides, which has nothing to do with the fact that there is no memory available to fill the buffers in the first place. They are 2 separate issues; the memory issue causes the eepro100 issue to occur regularly. Dennis > - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
