Hi, Reviewing the ethernet driver, I can see couple of bugs:
1) In stm32_freeframe, it should free all the buffers, and not just the first one. So remove the "if ((txdesc->des3 & ETH_TDES3_RD_FD) != 0)" That may cause it run out of buffers. 2) In stm32_freesegment, the order of getting the next descriptor, and updating the tail pointer is wrong. It should first call the stm32_get_next_rxdesc and only after that the stm32_putreg((uintptr_t)rxdesc, STM32_ETH_DMACRXDTPR); This is not fatal, but leads to the driver not using one of the desciptors and buffers at all (there is one less buffer in use and wasted memory for that). I am very sorry, but I am unable to provide any patches currently. Regards, Jukka On 20.2.2020 9.03, Reto Gähwiler wrote: > @Gregory: Thanks for your responses and input, will see what I can do. > > On 2020/02/19 22:50:02, Gregory Nutt <spudan...@gmail.com> wrote: >> >>> This sounds a lot like the problem I'm having with the SAMA5D36 Gigabit >>> ethernet... I'm running into some kind of deadlock on long transfers that >>> send packets very quickly. NuttX seems to run out of IOBs and then can't >>> send or respond to network packets. >>> >>> I tried increasing the low priority worker threads to 2 (and also 3) but >>> neither of them solved the problem. >>> >>> I'll look at the net_lock() to see if there's a way to release it. >>> >>> If you find a solution, I would love to know it! If I find one, I'll post >>> it here. >> >> The first step in debugging a deadlock is to find what is stuck waiting >> for what resource. >> >> Then find the logic that provides the resource that is being waited on. >> >> Then figure out why that logic is not running. Most likely, it would be >> waiting the low priority work queue. >> >> I have had to solve lots of problems like this. It is not really so >> difficult once you unstand the above things. >> >> >> >>
