lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 29 Jan 2018 18:12:26 +0800
From:   Chris Chiu <>
        Linux Kernel <>,
        Linux Upstreaming Team <>
Subject: Re: r8169 take too long to complete driver initialization

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
>> 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.

    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

    In mainline r8169.c, the IBISR0 register need to be polled in the
In the patch file, there's also the same IBISR0 polling code in
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
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?


Powered by blists - more mailing lists