From: Chris Chiu <hidden> Date: 2017-12-20 08:41:50
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
From: Chris Chiu <hidden> Date: 2018-01-05 02:17:38
On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu [off-list ref] 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
From: Chris Chiu <hidden> Date: 2018-01-29 10:12:30
On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu [off-list ref] wrote:
On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu [off-list ref] wrote:
quoted
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
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, &rtl_ocp_tx_cond, 50, 2000);
+ rtl_msleep_loop_wait_high(tp, &rtl_ocp_tx_cond, 50, 2000);
RTL_W8(IBISR0, RTL_R8(IBISR0) | 0x20);
RTL_W8(IBCR0, RTL_R8(IBCR0) & ~0x01);
}
Thanks.
------Please consider the environment before printing this e-mail.
-----Original Message-----
From: Chris Chiu [mailto:chiu@endlessm.com]
Sent: Monday, January 29, 2018 6:12 PM
To: nic_swsd <redacted>; netdev@vger.kernel.org; Linux
Kernel [off-list ref]; Linux Upstreaming Team
[off-list ref]
Subject: Re: r8169 take too long to complete driver initialization
On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu [off-list ref] wrote:
quoted
On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu [off-list ref] wrote:
quoted
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
------Please consider the environment before printing this e-mail.
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
quoted
-----Original Message-----
From: Chris Chiu [mailto:chiu@endlessm.com]
Sent: Monday, January 29, 2018 6:12 PM
To: nic_swsd <redacted>; netdev@vger.kernel.org; Linux
Kernel [off-list ref]; Linux Upstreaming Team
[off-list ref]
Subject: Re: r8169 take too long to complete driver initialization
On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu [off-list ref] wrote:
quoted
On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu [off-list ref] wrote:
quoted
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
------Please consider the environment before printing this e-mail.
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
quoted
quoted
-----Original Message-----
From: Chris Chiu [mailto:chiu@endlessm.com]
Sent: Monday, January 29, 2018 6:12 PM
To: nic_swsd <redacted>; netdev@vger.kernel.org; Linux
Kernel [off-list ref]; Linux Upstreaming Team
[off-list ref]
Subject: Re: r8169 take too long to complete driver initialization
On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu [off-list ref] wrote:
quoted
On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu [off-list ref] wrote:
quoted
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
------Please consider the environment before printing this e-mail.
-----Original Message-----
From: Chris Chiu [mailto:chiu@endlessm.com]
Sent: Friday, February 2, 2018 10:03 AM
To: Hau <redacted>
Cc: nic_swsd <redacted>; netdev@vger.kernel.org; Linux
Kernel [off-list ref]; Linux Upstreaming Team
[off-list ref]
Subject: Re: r8169 take too long to complete driver initialization
On Tue, Jan 30, 2018 at 8:07 PM, Chris Chiu [off-list ref] wrote:
quoted
On Mon, Jan 29, 2018 at 11:24 PM, Hau [off-list ref] wrote:
-----Original Message-----
From: Chris Chiu [mailto:chiu@endlessm.com]
Sent: Monday, January 29, 2018 6:12 PM
To: nic_swsd <redacted>; netdev@vger.kernel.org; Linux
Kernel [off-list ref]; Linux Upstreaming Team
[off-list ref]
Subject: Re: r8169 take too long to complete driver initialization
On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu [off-list ref] wrote:
quoted
On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu [off-list ref]
wrote:
quoted
quoted
quoted
quoted
quoted
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.
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
quoted
quoted
quoted
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?
quoted
quoted
quoted
Chris
------Please consider the environment before printing this e-mail.
From: Chris Chiu <hidden> Date: 2018-02-05 04:15:52
On Fri, Feb 2, 2018 at 7:49 PM, Hau [off-list ref] wrote:
quoted
-----Original Message-----
From: Chris Chiu [mailto:chiu@endlessm.com]
Sent: Friday, February 2, 2018 10:03 AM
To: Hau <redacted>
Cc: nic_swsd <redacted>; netdev@vger.kernel.org; Linux
Kernel [off-list ref]; Linux Upstreaming Team
[off-list ref]
Subject: Re: r8169 take too long to complete driver initialization
On Tue, Jan 30, 2018 at 8:07 PM, Chris Chiu [off-list ref] wrote:
quoted
On Mon, Jan 29, 2018 at 11:24 PM, Hau [off-list ref] wrote:
------Please consider the environment before printing this e-mail.
quoted
quoted
quoted
quoted
-----Original Message-----
From: Chris Chiu [mailto:chiu@endlessm.com]
Sent: Monday, January 29, 2018 6:12 PM
To: nic_swsd <redacted>; netdev@vger.kernel.org; Linux
Kernel [off-list ref]; Linux Upstreaming Team
[off-list ref]
Subject: Re: r8169 take too long to complete driver initialization
On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu [off-list ref] wrote:
quoted
On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu [off-list ref]
wrote:
quoted
quoted
quoted
quoted
quoted
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.
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
quoted
quoted
quoted
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?
quoted
quoted
quoted
Chris
------Please consider the environment before printing this e-mail.