[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
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 ?