I have an identical problem to the ETH_IRQHandler() interrupt bug described on the original thread with this title (i.e. TCPNet / Ethernet - Preventing 'interrupt storm')
i.e. OS_ERR_FIFO_OVF gets raised, and the network crashes. I was hoping to monitor the TCP socket traffic in order to get an idea of why the network crash occurs and raised a separate thread "ARM: Definitive guide to using Net_Debug", but unfortunately didn't receive any feedback on that.
I've implemented the fix described in the original thread (i.e. swap ETH->DMASR = INT_RBUIE; for ETH->DMASR = (INT_AISE | INT_RBUIE);) and the system appears to be holding up so far. But I'd really like to know the nature of this bug. What are the circumstances that cause this system crash ? What socket traffic causes the TCPNet to hang ?
It would be really nice to get definitive closure on this issue. For everyone's benefit.
In MDK5 driver, this problem is solved. The concept of processing Rx data is changed and this prevents Ethernet interrupt storm problem.
The interrupt handler does nothing more than sends a notification to ethernet thread in the library. This action is fast and takes only a few us. Then the thread, which runs in high priority reads the frame from DMA and releases DMA block.
If packets are coming too fast, ethernet receive DMA fills all available DMA blocks, and Rx DMA is stalled. In this state, Rx DMA does not generate further Rx interrupts. All Rx packets are dumped by ethernet controller without CPU intervention. Receiving process resumes, when the ethernet thread reads a packet from Rx DMA block and releases the block back to ETH-DMA.
Hi Franc, thanks for the feedback, that's useful to know.
Øyvind, thanks for your support. As suggested we tried our own DOS attack (with the interrupt fix in place) and everything stood up fine. We have also been soaking our system over the weekend and it's error free.