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

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

Hi Chris

On 20.10.2026 22:36, Chris Babroski wrote:
> [...]

> Interestingly, we are consistently seeing FCT_TX_USED=0x34 when
> reproducing the TX hang. We have FCT_TX_FIFO_END=0x27, default of 20kB,
> so it is mostly empty when we reproduce. 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?

> 
>> Is the MAC in LPI, or paused by the link partner? Does it still happen
>> with EEE and rx pause turned off?
> 
> In all repro cases so far the MAC does not appear to be in LPI and EEE
> is disabled (MAC_CR=0x200C and EEE_EN is clear). I also tested with
> "ethtool -A <if> autoneg off rx off tx off" and could still reproduce
> the tx hang.
> 
> We have a PCIe switch connecting the NIC to our SoC and on the switch I
> can see that the NIC's read requests drop to ~0 implying that it stops
> fetching TX data and descriptors rather than the MAC stopping queue
> drain.

Which one? Ours sit behind a Pericom PI7C9X2G404.

> 
>> The other place to look is the PCIe link. We had a LAN7430 stall on a
>> BCM2712 root complex that was also platform specific. The RC driver
>> cleared an undocumented bit in its CLKREQ#/L1 control register. That
>> one took the whole MMIO window down, so it is probably a different
>> failure, but it took days of uptime to show up too. Do the Device 
>> Status
>> or AER registers on the hung device show anything (UnsupReq, CmpltTO)?
>> Is the link running with ASPM L1 or L1 substates on that platform?
> 
> I do think the PCIe link could be related; our current best guess is
> that there is some issue between the NIC and PCIe switch and we have
> tickets open with both vendors to help debug (along with setting up 
> EVBs
> to run comparison tests on).
> 
> UnsupReq and CmpltTO appear clean. ASPM and L1 substates are disabled;
> the link stays in L0 at 2.5 GT/s x1.
> 
> 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?

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?

> [...]

Regards,
Nicolai