[PATCH 1/6] net: dwc_eth_qos: Fully rewrite RX descriptor field 3

[Marek Vasut]

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 ?

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?