Re: r8169 take too long to complete driver initialization
On Fri, Feb 2, 2018 at 7:49 PM, Hau <h...@realtek.com> wrote:
>
>> -Original Message-
>> From: Chris Chiu [mailto:c...@endlessm.com]
>> Sent: Friday, February 2, 2018 10:03 AM
>> To: Hau <h...@realtek.com>
>> Cc: nic_swsd <nic_s...@realtek.com>; netdev@vger.kernel.org; Linux
>> Kernel <linux-ker...@vger.kernel.org>; Linux Upstreaming Team
>> <li...@endlessm.com>
>> Subject: Re: r8169 take too long to complete driver initialization
>>
>> On Tue, Jan 30, 2018 at 8:07 PM, Chris Chiu <c...@endlessm.com> wrote:
>> > On Mon, Jan 29, 2018 at 11:24 PM, Hau <h...@realtek.com> wrote:
>> >> Hi Chris,
>> >>
>> >> Could you test following patch?
>> >>
>> >> DECLARE_RTL_COND(rtl_ocp_tx_cond)
>> >> {
>> >> void __iomem *ioaddr = tp->mmio_addr;
>> >>
>> >> - return RTL_R8(IBISR0) & 0x02;
>> >> + return RTL_R8(IBISR0) & 0x20;
>> >> }
>> >>
>> >> static void rtl8168ep_stop_cmac(struct rtl8169_private *tp) {
>> >> void __iomem *ioaddr = tp->mmio_addr;
>> >>
>> >> RTL_W8(IBCR2, RTL_R8(IBCR2) & ~0x01);
>> >> - rtl_msleep_loop_wait_low(tp, _ocp_tx_cond, 50, 2000);
>> >> + rtl_msleep_loop_wait_high(tp, _ocp_tx_cond, 50, 2000);
>> >> RTL_W8(IBISR0, RTL_R8(IBISR0) | 0x20);
>> >> RTL_W8(IBCR0, RTL_R8(IBCR0) & ~0x01); }
>> >>
>> >> Thanks.
>> >>
>> >
>> > Yes. It completes the initialization in 70 ms. So it means the
>> > rtl_ocp_tx_cond are waiting for incorrect register bit? Can you help work
>> out a patch for this?
>> >
>> > Chris
>> >
>> >
>>
>> Gentle ping,
>> cheers.
>>
>> Chris
>>
>
> I have submitted the patch to kernel team.
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=086ca23d03c0d2f4088f472386778d293e15c5f6
>
>
Cool. Thanks for this.
Chris
> --Please consider the environment before printing this e-mail.
>
>> >>> -Original Message-
>> >>> From: Chris Chiu [mailto:c...@endlessm.com]
>> >>> Sent: Monday, January 29, 2018 6:12 PM
>> >>> To: nic_swsd <nic_s...@realtek.com>; netdev@vger.kernel.org; Linux
>> >>> Kernel <linux-ker...@vger.kernel.org>; Linux Upstreaming Team
>> >>> <li...@endlessm.com>
>> >>> Subject: Re: r8169 take too long to complete driver initialization
>> >>>
>> >>> On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu <c...@endlessm.com> wrote:
>> >>> > On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu <c...@endlessm.com>
>> 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 :02:00.0 (unnamed net_device)
>> >>> >> (uninitialized): rtl_ocp_tx_cond == 1 (loop: 2000, delay: 50).
>> >>> >> [ 140.413294] r8169 :02:00.0 eth0: RTL8168ep/8111ep at
>> >>> >> 0xb16c80db1000, f8:0f:41:ea:74:0d, XID 10200800 IRQ 46 [
>> >>> >> 140.413297] r8169 :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 considere
Re: r8169 take too long to complete driver initialization
On Tue, Jan 30, 2018 at 8:07 PM, Chris Chiu <c...@endlessm.com> wrote:
> On Mon, Jan 29, 2018 at 11:24 PM, Hau <h...@realtek.com> wrote:
>> Hi Chris,
>>
>> Could you test following patch?
>>
>> DECLARE_RTL_COND(rtl_ocp_tx_cond)
>> {
>> void __iomem *ioaddr = tp->mmio_addr;
>>
>> - return RTL_R8(IBISR0) & 0x02;
>> + return RTL_R8(IBISR0) & 0x20;
>> }
>>
>> static void rtl8168ep_stop_cmac(struct rtl8169_private *tp)
>> {
>> void __iomem *ioaddr = tp->mmio_addr;
>>
>> RTL_W8(IBCR2, RTL_R8(IBCR2) & ~0x01);
>> - rtl_msleep_loop_wait_low(tp, _ocp_tx_cond, 50, 2000);
>> + rtl_msleep_loop_wait_high(tp, _ocp_tx_cond, 50, 2000);
>> RTL_W8(IBISR0, RTL_R8(IBISR0) | 0x20);
>> RTL_W8(IBCR0, RTL_R8(IBCR0) & ~0x01);
>> }
>>
>> Thanks.
>>
>
> Yes. It completes the initialization in 70 ms. So it means the rtl_ocp_tx_cond
> are waiting for incorrect register bit? Can you help work out a patch for
> this?
>
> Chris
>
>
Gentle ping,
cheers.
Chris
>>> -Original Message-
>>> From: Chris Chiu [mailto:c...@endlessm.com]
>>> Sent: Monday, January 29, 2018 6:12 PM
>>> To: nic_swsd <nic_s...@realtek.com>; netdev@vger.kernel.org; Linux
>>> Kernel <linux-ker...@vger.kernel.org>; Linux Upstreaming Team
>>> <li...@endlessm.com>
>>> Subject: Re: r8169 take too long to complete driver initialization
>>>
>>> On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu <c...@endlessm.com> wrote:
>>> > On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu <c...@endlessm.com> 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 :02:00.0 (unnamed net_device)
>>> >> (uninitialized): rtl_ocp_tx_cond == 1 (loop: 2000, delay: 50).
>>> >> [ 140.413294] r8169 :02:00.0 eth0: RTL8168ep/8111ep at
>>> >> 0xb16c80db1000, f8:0f:41:ea:74:0d, XID 10200800 IRQ 46 [
>>> >> 140.413297] r8169 :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
>>>
>>> --Please consider the environment before printing this e-mail.
Re: r8169 take too long to complete driver initialization
On Mon, Jan 29, 2018 at 11:24 PM, Hau <h...@realtek.com> wrote:
> Hi Chris,
>
> Could you test following patch?
>
> DECLARE_RTL_COND(rtl_ocp_tx_cond)
> {
> void __iomem *ioaddr = tp->mmio_addr;
>
> - return RTL_R8(IBISR0) & 0x02;
> + return RTL_R8(IBISR0) & 0x20;
> }
>
> static void rtl8168ep_stop_cmac(struct rtl8169_private *tp)
> {
> void __iomem *ioaddr = tp->mmio_addr;
>
> RTL_W8(IBCR2, RTL_R8(IBCR2) & ~0x01);
> - rtl_msleep_loop_wait_low(tp, _ocp_tx_cond, 50, 2000);
> + rtl_msleep_loop_wait_high(tp, _ocp_tx_cond, 50, 2000);
> RTL_W8(IBISR0, RTL_R8(IBISR0) | 0x20);
> RTL_W8(IBCR0, RTL_R8(IBCR0) & ~0x01);
> }
>
> Thanks.
>
Yes. It completes the initialization in 70 ms. So it means the rtl_ocp_tx_cond
are waiting for incorrect register bit? Can you help work out a patch for this?
Chris
>> -Original Message-
>> From: Chris Chiu [mailto:c...@endlessm.com]
>> Sent: Monday, January 29, 2018 6:12 PM
>> To: nic_swsd <nic_s...@realtek.com>; netdev@vger.kernel.org; Linux
>> Kernel <linux-ker...@vger.kernel.org>; Linux Upstreaming Team
>> <li...@endlessm.com>
>> Subject: Re: r8169 take too long to complete driver initialization
>>
>> On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu <c...@endlessm.com> wrote:
>> > On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu <c...@endlessm.com> 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 :02:00.0 (unnamed net_device)
>> >> (uninitialized): rtl_ocp_tx_cond == 1 (loop: 2000, delay: 50).
>> >> [ 140.413294] r8169 :02:00.0 eth0: RTL8168ep/8111ep at
>> >> 0xb16c80db1000, f8:0f:41:ea:74:0d, XID 10200800 IRQ 46 [
>> >> 140.413297] r8169 :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
>>
>> --Please consider the environment before printing this e-mail.
Re: r8169 take too long to complete driver initialization
On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu <c...@endlessm.com> wrote: > On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu <c...@endlessm.com> 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 :02:00.0 (unnamed net_device) >> (uninitialized): rtl_ocp_tx_cond == 1 (loop: 2000, delay: 50). >> [ 140.413294] r8169 :02:00.0 eth0: RTL8168ep/8111ep at >> 0xb16c80db1000, f8:0f:41:ea:74:0d, XID 10200800 IRQ 46 >> [ 140.413297] r8169 :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
Re: r8169 take too long to complete driver initialization
On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu <c...@endlessm.com> 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 :02:00.0 (unnamed net_device) > (uninitialized): rtl_ocp_tx_cond == 1 (loop: 2000, delay: 50). > [ 140.413294] r8169 :02:00.0 eth0: RTL8168ep/8111ep at > 0xb16c80db1000, f8:0f:41:ea:74:0d, XID 10200800 IRQ 46 > [ 140.413297] r8169 :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.
r8169 take too long to complete driver initialization
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 :02:00.0 (unnamed net_device) (uninitialized): rtl_ocp_tx_cond == 1 (loop: 2000, delay: 50). [ 140.413294] r8169 :02:00.0 eth0: RTL8168ep/8111ep at 0xb16c80db1000, f8:0f:41:ea:74:0d, XID 10200800 IRQ 46 [ 140.413297] r8169 :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
