[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8c0a80fe-5e92-42c4-88cc-0fc46c17a936@lunn.ch>
Date: Thu, 27 Feb 2025 17:02:54 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Mark Pearson <mpearson-lenovo@...ebb.ca>
Cc: anthony.l.nguyen@...el.com, przemyslaw.kitszel@...el.com,
andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com,
intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] e1000e: Link flap workaround option for false IRP events
> The reason for the module option is I'm playing it safe, as Intel couldn't determine root cause.
> The aim of the patch is to keep the effect to a minimum whilst
> allowing users who are impacted to turn on the workaround, if they
> are encountering the issue.
And how do such users determine this module parameter exists? You need
to be a pretty savvy user to know about them, and how the set them,
etc.
> Issue details:
> We have seen the issue when running high level traffic on a network
> involving at least two nodes and also having two different network
> speeds are need. For example:
> [Lenovo WS] <---1G link---> Network switch <---100M link--->[traffic source]
> The link flap can take a day or two to reproduce - it's rare.
By flap, you mean down/up? So the network dies for a couple of seconds
while autoneg happens? And this repeats at 1 to 2 day intervals?
Or does the link go down, and stay down, and it needs user
intervention to get the link back?
Andrew
Powered by blists - more mailing lists