From patchwork Sun Feb 24 22:04:13 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Francois Romieu X-Patchwork-Id: 222800 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 5C4FE2C0298 for ; Mon, 25 Feb 2013 09:36:26 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759203Ab3BXWgV (ORCPT ); Sun, 24 Feb 2013 17:36:21 -0500 Received: from violet.fr.zoreil.com ([92.243.8.30]:38181 "EHLO violet.fr.zoreil.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759153Ab3BXWgU (ORCPT ); Sun, 24 Feb 2013 17:36:20 -0500 Received: from violet.fr.zoreil.com (localhost [127.0.0.1]) by violet.fr.zoreil.com (8.13.8/8.13.8) with ESMTP id r1OM4EBW022905; Sun, 24 Feb 2013 23:04:14 +0100 Received: (from romieu@localhost) by violet.fr.zoreil.com (8.13.8/8.13.8/Submit) id r1OM4DvW022904; Sun, 24 Feb 2013 23:04:13 +0100 Date: Sun, 24 Feb 2013 23:04:13 +0100 From: Francois Romieu To: Tomi Orava Cc: Stephen Hemminger , netdev@vger.kernel.org Subject: Re: Fw: [Bug 54231] r8169 driver regression caused by the commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd Message-ID: <20130224220413.GA22870@electric-eye.fr.zoreil.com> References: <20130222095546.396e63a8@nehalam.linuxnetplumber.net> <20130222230908.GB4248@electric-eye.fr.zoreil.com> <512A2BB0.9050803@ncircle.nullnet.fi> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <512A2BB0.9050803@ncircle.nullnet.fi> User-Agent: Mutt/1.4.2.2i X-Organisation: Land of Sunshine Inc. Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Tomi Orava : > On 02/23/2013 01:09 AM, Francois Romieu wrote: [...] > I started re-testing after your comment and figured out that the > real problem seems to lie somehow with jumbo frames. Ie. the DMA burst > changes do not actually prevent the hangs at all in my case. The > catch here, that I missed previously, was that for some interesting > reason the NIC will fail in a couple of minutes with a suitable traffic > if the jumbo frames (mtu 4000) have been enabled from the start. > However, if I enable the jumbo frames manually after the system > has already started up, there are no stability issues related to network. If you mean that 'ip link set dev ... mtu 4000; ip link set dev ... up' fails whereas 'ip link set dev ... up; ip link set dev ... mtu 4000' works, the patch below is a candidate: --- [...] > > Tomi, what does lspci say about your 8168b device ? > > The NIC information is: > > 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI > Express Gigabit Ethernet controller (rev 01) > > 03:00.0 0200: 10ec:8168 (rev 01) Ok, so the first hunk of the patch that Stephen forwarded would not make any difference for your chipset. diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index 8900398..af99498 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -4766,7 +4766,7 @@ static void rtl_hw_start_8168bb(struct rtl8169_private *tp) RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R8168_CPCMD_QUIRK_MASK); rtl_tx_performance_tweak(pdev, - (0x5 << MAX_READ_REQUEST_SHIFT) | PCI_EXP_DEVCTL_NOSNOOP_EN); + (0x2 << MAX_READ_REQUEST_SHIFT) | PCI_EXP_DEVCTL_NOSNOOP_EN); } static void rtl_hw_start_8168bef(struct rtl8169_private *tp)