Re: [lwip-users] Receive path stuck due to pbuf_alloc returning NULL

[Sergio R. Caprile]

If your device does not go to the Eth Rx ISR that is because either the
controller is not interrupting anymore or the OS is not accepting the IRQ.
pbuf_alloc() does not control your chip, your driver does.
Your driver should gracefully discard the incoming frame if it can't
accept its contents (put them in a pbuf).
This should also include letting the chip in a useful state so it can
interrupt again, and refrain from writing anywhere; something like:

        p = pbuf_alloc(PBUF_RAW, somesize, PBUF_POOL);
        if (p != NULL) {
                // handle the data from the chip to the pbuf
        } else {
                // LINK_STATS_INC(link.memerr); was useful long time ago, and I 
guess
it still is
                // flush the chip so it "thinks data has been delivered", I 
read it
anyway like if delivering, ymmv
                return; // can't go ahead, and next frame will likely have to be
discarded too... mmm... ymmv
        }
        // perhaps check some packet types and eventually
        if (netif->input(p, netif != ERROR_OK))
                pbuf_free(p);
        // but if you will not deliver, then pbuf_free(p);

Perhaps your driver is not checking returned value and goes ahead when
it shouldn't ?
Maybe your driver does check the value and forgets to properly care for
the controller when there is no place to put the data ?