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

quoted

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.

Which one? Ours sit behind a Pericom PI7C9X2G404.

Oh, we are also using a Diodes switch, the PI7C9X3G606GP.

quoted

Recently we found that after every reproduced hang we see that the NIC
sent a NAK to the switch, potentially in response to a CplD from switch
while reading TX data and descriptors, but I am not yet able to see the
rejected TLP or NAK reason with my setup.

Then BadTLP/BadDLLP on the NIC and Rollover/Timeout on the switch port
should tell what went wrong with the replay. Are those clean too?

Those all appear to be clean too (based on NIC's receive error
counters and firmware AER logging). Occasionally we see replay timer
timeouts reported from the switch on port connected to NIC, but they
occur even without the TX hang and don't always occur when there is a
TX hang.

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.

Thanks,
Chris