[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Sergio R. Caprile
Subject: Re: [lwip-users] Receive path stuck due to pbuf_alloc returning NULL
Date: Fri, 22 Mar 2019 11:08:51 -0300
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Thunderbird/60.6.0

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 
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))
        // 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 ?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]