MACB driver: ethernet packet fragment not being sent in time
Posted: Fri Apr 20, 2018 1:38 pm
I'm using a SAMA5d4 custom board, building Linux image using Yocto Project, Rocko.
Kernel version used: 4.14.14
I have a web server running on this device -serving pages, a python script running on another machine (Linux) makes HTTP requests.
Problem:
A lot of requests are ok, completely served to the client.
Randomly, one connection times out on the client side - I've tracked this problem down to the MACB driver[1]
Investigating using wireshark, client side, I see that the last frame of the response doesn't reach the client, the client times out after 10 seconds, closes the connection (sends FIN ACK), then I immediately see the lost packet arriving.
tcpdump on the SAMA5d4 custom board says that the frame has been 'sent' in time, along with the others.
In the MACB driver, I've added some logs. Basically I’ve been looking at the function that is called for starting the transmission,
macb_start_xmit() and the one that is called after transmission is complete, macb_tx_interrupt().
I’ve add logs containing packet lengths, and I've observed that the missing frame is being mapped for DMA transfer in time, at around the same time with the previous ones (in sync with what I see in tcpdump server side), but I get the corresponding interrupt (in macb_tx_interrupt()) only after 10 seconds (the timeout) - for some reason it's ignored by the hardware (?).
That packet is confirmed to be sent [2] only after a new one is enqueued: the response for the client's FIN ACK - they are both sent
Do you have knowledge of such an issue or hints how to proceed ?
Regards
[1]: https://git.kernel.org/pub/scm/linux/ke ... h=v4.14.14
[2]: https://git.kernel.org/pub/scm/linux/ke ... 14.14#n843
Kernel version used: 4.14.14
I have a web server running on this device -serving pages, a python script running on another machine (Linux) makes HTTP requests.
Problem:
A lot of requests are ok, completely served to the client.
Randomly, one connection times out on the client side - I've tracked this problem down to the MACB driver[1]
Investigating using wireshark, client side, I see that the last frame of the response doesn't reach the client, the client times out after 10 seconds, closes the connection (sends FIN ACK), then I immediately see the lost packet arriving.
tcpdump on the SAMA5d4 custom board says that the frame has been 'sent' in time, along with the others.
In the MACB driver, I've added some logs. Basically I’ve been looking at the function that is called for starting the transmission,
macb_start_xmit() and the one that is called after transmission is complete, macb_tx_interrupt().
I’ve add logs containing packet lengths, and I've observed that the missing frame is being mapped for DMA transfer in time, at around the same time with the previous ones (in sync with what I see in tcpdump server side), but I get the corresponding interrupt (in macb_tx_interrupt()) only after 10 seconds (the timeout) - for some reason it's ignored by the hardware (?).
That packet is confirmed to be sent [2] only after a new one is enqueued: the response for the client's FIN ACK - they are both sent
Do you have knowledge of such an issue or hints how to proceed ?
Regards
[1]: https://git.kernel.org/pub/scm/linux/ke ... h=v4.14.14
[2]: https://git.kernel.org/pub/scm/linux/ke ... 14.14#n843