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

[Patrick DELAUNAY]

Dear,

> From: Marek Vasut <marex at 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.

Regards

Patrick