From: Simon Horman <horms@kernel.org>
To: David Thompson <davthompson@nvidia.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, leon@kernel.org, yuehaibing@huawei.com,
andriy.shevchenko@linux.intel.com,
u.kleine-koenig@pengutronix.de, asmaa@nvidia.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v1] mlxbf_gige: disable RX filters until RX path initialized
Date: Mon, 12 Aug 2024 11:24:26 +0100 [thread overview]
Message-ID: <20240812102426.GB468359@kernel.org> (raw)
In-Reply-To: <20240809163612.12852-1-davthompson@nvidia.com>
On Fri, Aug 09, 2024 at 12:36:12PM -0400, David Thompson wrote:
> A recent change to the driver exposed a bug where the MAC RX
> filters (unicast MAC, broadcast MAC, and multicast MAC) are
> configured and enabled before the RX path is fully initialized.
> The result of this bug is that after the PHY is started packets
> that match these MAC RX filters start to flow into the RX FIFO.
> And then, after rx_init() is completed, these packets will go
> into the driver RX ring as well. If enough packets are received
> to fill the RX ring (default size is 128 packets) before the call
> to request_irq() completes, the driver RX function becomes stuck.
>
> This bug is intermittent but is most likely to be seen where the
> oob_net0 interface is connected to a busy network with lots of
> broadcast and multicast traffic.
>
> All the MAC RX filters must be disabled until the RX path is ready,
> i.e. all initialization is done and all the IRQs are installed.
>
> Fixes: f7442a634ac0 ("mlxbf_gige: call request_irq() after NAPI initialized")
> Reviewed-by: Asmaa Mnebhi <asmaa@nvidia.com>
> Signed-off-by: David Thompson <davthompson@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2024-08-12 10:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-09 16:36 [PATCH net v1] mlxbf_gige: disable RX filters until RX path initialized David Thompson
2024-08-12 10:24 ` Simon Horman [this message]
2024-08-13 13:50 ` patchwork-bot+netdevbpf
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=20240812102426.GB468359@kernel.org \
--to=horms@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=asmaa@nvidia.com \
--cc=davem@davemloft.net \
--cc=davthompson@nvidia.com \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=yuehaibing@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.