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

[Nicolai Buchwitz]

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