From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751404AbeA2KMa (ORCPT ); Mon, 29 Jan 2018 05:12:30 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:33527 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750959AbeA2KM2 (ORCPT ); Mon, 29 Jan 2018 05:12:28 -0500 X-Google-Smtp-Source: AH8x224bwFmHcdp1s5jdPHBdCufskUaoVi10qGAQAR6B+TCho5ZSHRz3cCZBKuSEpR0JZa2wR6QFuUPPMKWmjHiKdIw= MIME-Version: 1.0 In-Reply-To: References: From: Chris Chiu Date: Mon, 29 Jan 2018 18:12:26 +0800 Message-ID: Subject: Re: r8169 take too long to complete driver initialization To: nic_swsd@realtek.com, netdev@vger.kernel.org, Linux Kernel , Linux Upstreaming Team Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu wrote: > On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu wrote: >> Hi, >> We've hit a suspend/resume issue on a Acer desktop caused by r8169 >> driver. The dmseg >> https://gist.github.com/mschiu77/b741849b5070281daaead8dfee312d1a >> shows it's still in msleep() within a mutex lock. >> After looking into the code, it's caused by the >> rtl8168ep_stop_cmac() which is waiting 100 seconds for >> rtl_ocp_tx_cond. The following dmesg states that the r8169 driver is >> loaded. >> >> [ 20.270526] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded >> >> But it takes > 100 seconds to get the following messages >> >> [ 140.400223] r8169 0000:02:00.0 (unnamed net_device) >> (uninitialized): rtl_ocp_tx_cond == 1 (loop: 2000, delay: 50). >> [ 140.413294] r8169 0000:02:00.0 eth0: RTL8168ep/8111ep at >> 0xffffb16c80db1000, f8:0f:41:ea:74:0d, XID 10200800 IRQ 46 >> [ 140.413297] r8169 0000:02:00.0 eth0: jumbo features [frames: 9200 >> bytes, tx checksumming: ko] >> >> So any trial to suspend the machine during this period would always >> get device/resource busy message then abort. Is this rtl_ocp_tx_cond >> necessary? Because the ethernet is still working and I don't see any >> problem. I don't know it should be considered normal or not. Please >> let me know if any more information required. Thanks >> >> Chris > > gentle ping, > > cheers. Hi, Just found a r8168 driver which seems to be authrized by realtek for cross comparison. I tried applying the patch to latest 4.15 kernel and the driver done it's initialization in faily short time. The patch file is here https://gist.github.com/mschiu77/fcf406e64a1a437f46cf2be643f1057d. In mainline r8169.c, the IBISR0 register need to be polled in the rtl8168ep_stop_cmac(). In the patch file, there's also the same IBISR0 polling code in Dash2DisableTx(), but it's been bypassed since the chipset maches HW_DASH_SUPPORT_TYPE_2. Per the rtl_chip_info[] in r8168_n.c, CFG_METHOD_23/27/28 are HW_DASH_SUPPORT_TYPE_2, and they happens to be the only 3 named RTL8168EP/8111EP in the rtl_chip_info[]. To find the same matches in r8169.c, RTL_GIGA_MAC_VER_49/50/51 seems share the same config. Can anyone clarify if the rtl_ocp_tx_cond() really necessary for 8168EP/8111EP? Or we can just ignore the condition check for RTL_GIGA_MAC_VER_49/50/51? Chris