[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <309B89C4C689E141A5FF6A0C5FB2118B9703A79B@ORSMSX103.amr.corp.intel.com>
Date: Fri, 26 Apr 2019 00:05:02 +0000
From: "Brown, Aaron F" <aaron.f.brown@...el.com>
To: Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
CC: Sasha Levin <sashal@...nel.org>, Joseph Yasi <joe.yasi@...il.com>,
Alexander Duyck <alexander.duyck@...il.com>,
"e1000-devel@...ts.sourceforge.net"
<e1000-devel@...ts.sourceforge.net>
Subject: RE: [PATCH 2/2] e1000e: start network tx queue only when link is up
> From: Konstantin Khlebnikov [mailto:khlebnikov@...dex-team.ru]
> Sent: Wednesday, April 17, 2019 1:13 AM
> To: netdev@...r.kernel.org; intel-wired-lan@...ts.osuosl.org; linux-
> kernel@...r.kernel.org; Kirsher, Jeffrey T <jeffrey.t.kirsher@...el.com>
> Cc: Sasha Levin <sashal@...nel.org>; Joseph Yasi <joe.yasi@...il.com>;
> Brown, Aaron F <aaron.f.brown@...el.com>; Alexander Duyck
> <alexander.duyck@...il.com>; e1000-devel@...ts.sourceforge.net
> Subject: [PATCH 2/2] e1000e: start network tx queue only when link is up
>
> Driver does not want to keep packets in tx queue when link is lost.
> But present code only reset NIC to flush them, but does not prevent
> queuing new packets. Moreover reset sequence itself could generate
> new packets via netconsole and NIC falls into endless reset loop.
>
> This patch wakes tx queue only when NIC is ready to send packets.
>
> This is proper fix for problem addressed by commit 0f9e980bf5ee
> ("e1000e: fix cyclic resets at link up with active tx").
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
> Suggested-by: Alexander Duyck <alexander.duyck@...il.com>
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
Tested-by: Aaron Brown <aaron.f.brown@...el.com>
Again, more of a regression check than a test that the patch solves the problem as I did not manage to trigger the hang.
Powered by blists - more mailing lists