Re: [PATCH net-next v1 0/5] net: lan743x: automatically recover from TX hang

[Nicolai Buchwitz <nb@tipi-net.de>]

Hi Chris

On 21.10.2026 21:23, Chris Babroski wrote:
>>> Is there anything special about the 52 byte usage?
>> 
>> Not that I know of. It looks like the head of a scatter-gather frame
>> whose fragments never came in. Does it match the buffer_length of the
>> first active descriptor at tx->last_head?
> 
> Yes, you're right, tx->last_head is pointing to the header of a TSO
> frame and the consistent 52 bytes was just an artifact of the test
> data I was using to reproduce this week which creates a 54-byte
> header. FCT_TX_USED is 52 bytes, but tx->last_head has a buffer_length
> of 54, so not sure where the 2 byte difference comes from. TX_HEAD
> stopped at the frame's payload descriptor, after the TSO extension
> descriptor.

AN2948 5.2.9 says FCT_TX_USED counts the frame length rounded up to a
dword plus the command words, so a 54 byte header should read 56 or
more. 52 does not add up, so I would leave that to Microchip.

The same document lists TX_ERR_STS0 with TX_DATA_READ_ERR and
TX_DESC_READ_ERR, set when a PCIe read failed "and all retries have
been used", and FCT_TXE for a failed FCT sanity check. They land in
DMAC_INT_STS bit 21, which the driver never enables or reads. What do
TX_ERR_STS0, DMAC_INT_STS and FCT_INT_STS show while it hangs?

DMAC_CFG MAX_READ_REQ is not a size either. It is the number of
outstanding TX data reads, 1 to 6, and the driver sets 6. Does the
hang survive MAX_READ_REQ = 1?

> 
>> Which one? Ours sit behind a Pericom PI7C9X2G404.
> 
> Oh, we are also using a Diodes switch, the PI7C9X3G606GP.

Same family then - and I it's known to have it quirks ...
Ours is the Gen2 part at 2.5 GT/s and has not hung so far, but that
port sees little TX load. If you can share the reproducer I can run it 
here.

> [...]

>> My guess: the replay hands the NIC a completion it had already 
>> counted,
>> and the DMA engine then waits for data that never comes, with nothing
>> in the error registers.
>> 
>> Lowering MaxReadReq to 128 bytes with setpci would be a cheap way to
>> test that?
> 
> Unfortunately, we can still reproduce with MaxReadReq set to 128.
> Using the same test as mentioned previously, the FCT_TX_USED now shows
> the header plus ~1 KB of payload data instead of 52 bytes.

So not the request size. What is left in the driver is the descriptor
prefetch. lan743x_tx_open() sets TX_PF_THRES to 0x10 and
TX_PF_PRI_THRES to 4, and the prefetcher works hardest with a full
ring, which is when you see the most hangs. Does TX_PF_THRES 1 change
the rate?

> [...]

Regards,
Nicolai