benpicco
benpicco
It also happens with DOSE, but I think a second interface was required to trigger this (will try to reproduce this with a single one)
> Mh, I don't have that board and trying to reproduce with `samr21-xpro` yields the expected results. `at86rf2xx` does not use `gnrc_pktqueue` > Trying on a similar particle-xenon I face...
It's not immediate, it takes several minutes, I don't have found a quick way yet to trigger the condition.
I'm afraid this might not be related to `gnrc_netif_pktq` but to pktbuf in general with concurrent allocation and freeing: I have a board with a SLIP and an `atwinc15x0` interface....
I now have a quite reliable way to trigger the condition, requires sending on one interface while also receiving data on a another interface. pktbuf remains full after I stop...
I've added some more tracing to also log the place where the pktbuf allocation was made [`pktbuf.log`](https://pastebin.pl/view/07259ceb): - `10b63`: `sys/net/gnrc/netif/ethernet/gnrc_netif_ethernet.c:182` - `10ba3`: `sys/net/gnrc/netif/ethernet/gnrc_netif_ethernet.c:217 (discriminator 8)` - `10bcf`: `sys/net/gnrc/netif/ethernet/gnrc_netif_ethernet.c:240` - `13473`:...
Ok, this turns out to be an unrelated issue. The sending thread did not call `sock_udp_recv()` even though it was getting replies to the local port, filling up the mbox....
Yes the (unrelated to this issue) issue triggered is now resolved by #18143 and #18147 - but `gnrc_netif_pktq` is still leaky.
Only now did I realize that there is already a pull request for this #94
@valkuc just run `make` in the `src/fuse` directory. You have to provide a `spiffs_config.h`. If you want to use the one from the `default/` folder, just run `make TEST=1`. Then...