On 4/7/20 3:19 PM, Patrick DELAUNAY wrote: > Dear, > >> From: Marek Vasut <ma...@denx.de> >> Sent: mardi 7 avril 2020 12:04 >> >> On 4/7/20 11:49 AM, Patrick DELAUNAY wrote: >>> Dear Marek, >> >> Hi, >> >>> To complete my test and to check the cache management in the driver, >>> >>> I test the sequence (CONFIG_SYS_NONCACHED_MEMORY is activated): >>> >>> 1) ping with dcache ON: Always OK >>> >>> STM32MP> dhcp >>> STM32MP> ping 91.162.57.93 >>> >>> 2) ping with dcache OFF : Always OK >>> >>> STM32MP> dcache off >>> STM32MP> ping 91.162.57.93 >>> >>> 3) ping with dcache ON : Failed >>> >>> STM32MP> dcache on >>> STM32MP> ping 91.162.57.93 >>> >>> Failed with "eqos_send: TX timeout" >>> and after "eqos_recv: RX packet not available" >>> >>> 4) ping with dcache OFF : Always OK >>> >>> STM32MP> dcache on >>> STM32MP> ping 91.162.57.93 >>> >>> >>> I don't sure this sequence is really valid or if this issue show a >>> problem in cache management. >>> >>> As I don't see any obvious issue in eqos_send, do you idea on reason >>> of this issue ? >> >> So the test is basically: >> >> dhcp >> while true ; do >> ping 192.168.1.300 ; >> dcache off ; >> ping 192.168.1.300 ; >> dcache on ; >> done >> >> right ? > > Yes, exactly and it is more clear > >> >> I can tell you what you're likely gonna see if you debug it further. >> >> Use the board on an isolated network segment (get some USB ethernet or >> whatever), disable dhcp server, avahi and all other such stuff. Then run >> wireshark >> on that interface. >> >> Then, patch the dwmac driver to dump every packet it sends and receives, the >> first 16 or so bytes are enough, so you'd see the header. Then run your test. >> >> After a while, you will see that the DWMAC transmits some valid packet, but >> receives a packet with the exact same source MAC it just transmitted , the >> source >> MAC of the stm32 board. But if I recall it correctly, you won't see that >> packet on >> the line in wireshark, it just somehow loops back in. >> >> You can even accelerate that process by using arping from the host PC, just >> arping the stm32 and the error will happen faster. >> >> I was hoping I managed to fix all of these problems in this series, but >> apparently >> there is more :-( Do you feel like debugging this further? > > Yes it is my fear. > > Thanks for advices... > I will try to debug it > but my bandwith is limited for the next week, so I can't give a guarantee.
I sent a patch to pad the descriptors to cacheline size just now, however I still didn't get Joe to review/apply any of the networking patches. I hope he's just busy with other stuff ...