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

[Marek Vasut]

On 4/7/20 3:19 PM, Patrick DELAUNAY wrote:
> 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.

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 ...