TCPNet / Ethernet - Preventing 'interrupt storm' - REVISITED

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.

Parents
  • I did reply in your other thread, but you didn't follow up.

    Now, regarding the interrupt storm issue, I have had the same problem with Keil's ethernet driver for the NXP LPC23xx family (which is ARM7, not Cortex-M). The problem is that within the ethernet interrupt function, there is a loop that tries to exhaust (i.e read all received fragments) the RX-descriptors. If the ingress packet flow is high enough (try a DOS-attack), this loop will never end (because there will always be a new fragment to process), and the interrupt function never returns. This will of course kill the system, since nothing else is permitted to run.

    I have no experience with the CPU you are using, but it might be something similar that is happening.

    I "fixed" the problem by breaking the loop and disabling ethernet interrupts for a while if the packet flow was too high to handle. Packets will of course be lost, but it is better than entering a boot loop (due to the watchdog barking).

    Best regards
    -Øyvind

Reply
  • I did reply in your other thread, but you didn't follow up.

    Now, regarding the interrupt storm issue, I have had the same problem with Keil's ethernet driver for the NXP LPC23xx family (which is ARM7, not Cortex-M). The problem is that within the ethernet interrupt function, there is a loop that tries to exhaust (i.e read all received fragments) the RX-descriptors. If the ingress packet flow is high enough (try a DOS-attack), this loop will never end (because there will always be a new fragment to process), and the interrupt function never returns. This will of course kill the system, since nothing else is permitted to run.

    I have no experience with the CPU you are using, but it might be something similar that is happening.

    I "fixed" the problem by breaking the loop and disabling ethernet interrupts for a while if the packet flow was too high to handle. Packets will of course be lost, but it is better than entering a boot loop (due to the watchdog barking).

    Best regards
    -Øyvind

Children
More questions in this forum