Forum Discussion
Hi Girisha Dengi,
Hi Tiwari
I will do the test with 6.12 on Monday. In the mean time I found a few more informations.
It seams, that the issue is not directly a delay in processing the ethernet frames. It is more like an offset in the element processing.
I check the network packages in Wireshark. In the error case, I can send a first (single) ping package and wait for an answer.
As long as nothing else is sent over the Ethernet no answer is retuned. As soon as I send a second ping package i receive the answer from the first ping package on my host PC.
When I observe the tcpdump on the Arria 10 device, I see the first ping package and its response after sending the second one.
Based on this observation I tried to get more information about the HPS MAC status. The gmacgrp_debug register https://www.intel.com/content/www/us/en/programmable/hps/arria-10/hps.html#topic/sfo1429889363845.html reports 0x120 which means, that data are present in the Rx FIFO and that the read controller is in the state of "Reading Frame Data".
It seams, that it is some how stuck in this state, and no Data are transferred to the kernel descriptors. (I checked as well the descriptors in kernel, and the are all provided and ready to use for the Ethernet DMA)
So in my opinion it seams that MACs FIFO read controller is somehow out of sync and still waiting for the end of a frame to be triggered to transfer the data... The operation mode is "Store and forward" which some how waits for the frame end.
Is there a way to get more information of the read controller? And to trigger the read out manually? I think the issue is not necessary related with kernel version. I will do the test with 6.12 next week.
regards,
silvan
Hi I did some tests with kernel 6.12 and see the same issue. I still think the issue is some where in the Read Controller of the Rx FIFO inside the MAC IP.
Is there any further registers for debugging available? Or any state information which can help to find and solve the issue?
Regards,
Silvan