mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chris Babroski <cbabroski@nvidia.com>
To: <nb@tipi-net.de>
Cc: <Raju.Lakkaraju@microchip.com>, <UNGLinuxDriver@microchip.com>,
	<andrew+netdev@lunn.ch>, <bryan.whitehead@microchip.com>,
	<cbabroski@nvidia.com>, <davem@davemloft.net>,
	<davthompson@nvidia.com>, <edumazet@kernel.org>,
	<kuba@kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux@armlinux.org.uk>, <maxime.chevallier@bootlin.com>,
	<netdev@vger.kernel.org>, <pabeni@redhat.com>,
	<richardcochran@gmail.com>
Subject: Re: [PATCH net-next v1 0/5] net: lan743x: automatically recover from TX hang
Date: Wed, 21 Oct 2026 15:23:41 -0400	[thread overview]
Message-ID: <20261021192341.361517-1-cbabroski@nvidia.com> (raw)
In-Reply-To: <c0117e4e987c3bd349e56a979cbbdbc5@tipi-net.de>

>> 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.

>> 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

  reply	other threads:[~2026-10-21 19:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 15:00 Chris Babroski
2026-10-15 15:00 ` [PATCH net-next v1 1/5] net: lan743x: reset DMA channels that fail to stop Chris Babroski
2026-10-19 10:18   ` Nicolai Buchwitz
2026-10-21 19:53   ` Nicolai Buchwitz
2026-10-15 15:00 ` [PATCH net-next v1 2/5] net: lan743x: start phylink last and stop it first Chris Babroski
2026-10-19 10:13   ` Nicolai Buchwitz
2026-10-15 15:00 ` [PATCH net-next v1 3/5] net: lan743x: quiesce TX before freeing the rings Chris Babroski
2026-10-19 10:14   ` Nicolai Buchwitz
2026-10-21 18:20   ` Woojung.Huh
2026-10-15 15:00 ` [PATCH net-next v1 4/5] net: lan743x: reset the device on TX timeout Chris Babroski
2026-10-19 10:23   ` Nicolai Buchwitz
2026-10-15 15:00 ` [PATCH net-next v1 5/5] net: lan743x: add byte queue limits support Chris Babroski
2026-10-19 10:14   ` Nicolai Buchwitz
2026-10-19  9:47 ` [PATCH net-next v1 0/5] net: lan743x: automatically recover from TX hang Nicolai Buchwitz
2026-10-20 20:36   ` Chris Babroski
2026-10-21  8:06     ` Nicolai Buchwitz
2026-10-21 19:23       ` Chris Babroski [this message]
2026-10-21 19:48         ` Nicolai Buchwitz
2026-10-19 19:49 ` Woojung.Huh
2026-10-21  1:07 ` Jakub Kicinski
2026-10-21 14:03   ` Chris Babroski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261021192341.361517-1-cbabroski@nvidia.com \
    --to=cbabroski@nvidia.com \
    --cc=Raju.Lakkaraju@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=bryan.whitehead@microchip.com \
    --cc=davem@davemloft.net \
    --cc=davthompson@nvidia.com \
    --cc=edumazet@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=maxime.chevallier@bootlin.com \
    --cc=nb@tipi-net.de \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®