Re: [PATCH v3] net: macb: restart tx after tx used bit read

On Wed, 23 Mar 2022 10:08:20 +0200 Tomas Melin wrote:

quoted

From: <redacted>
To: <Nicolas.Ferre@microchip.com>, <davem@davemloft.net>
Cc: <redacted>, <redacted>,
	[off-list ref]
Subject: [PATCH v3] net: macb: restart tx after tx used bit read
Date: Mon, 17 Dec 2018 10:02:42 +0000	[thread overview]
Message-ID: [ref] (raw)

From: Claudiu Beznea <redacted>

On some platforms (currently detected only on SAMA5D4) TX might stuck
even the pachets are still present in DMA memories and TX start was
issued for them. This happens due to race condition between MACB driver
updating next TX buffer descriptor to be used and IP reading the same
descriptor. In such a case, the "TX USED BIT READ" interrupt is asserted.
GEM/MACB user guide specifies that if a "TX USED BIT READ" interrupt
is asserted TX must be restarted. Restart TX if used bit is read and
packets are present in software TX queue. Packets are removed from software
TX queue if TX was successful for them (see macb_tx_interrupt()).

Signed-off-by: Claudiu Beznea <redacted>  

On Xilinx Zynq the above change can cause infinite interrupt loop leading 
to CPU stall. Seems timing/load needs to be appropriate for this to happen, and currently
with 1G ethernet this can be triggered normally within minutes when running stress tests
on the network interface.

The events leading up to the interrupt looping are similar as the issue described in the
commit message. However in our case, restarting TX does not help at all. Instead
the controller is stuck on the queue end descriptor generating endless TX_USED           
interrupts, never breaking out of interrupt routine.

Any chance you remember more details about in which situation restarting TX helped for
your use case? was tx_qbar at the end of frame or stopped in middle of frame?

Which kernel version are you using? Robert has been working on macb +
Zynq recently, adding him to CC.