netdev - Re: issue with ethernet gigabit ethernet card both on stable and rc kernels

lists.openwall.net		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] [day] [month] [year] [list]

Message-ID: <37b1001d-688c-fa35-0d8a-cbbbae5e6fa8@gmail.com>
Date:   Fri, 20 Jan 2023 22:09:23 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     vmxevilstar@...il.com, nic_swsd@...ltek.com, netdev@...r.kernel.org
Subject: Re: issue with ethernet gigabit ethernet card both on stable and rc
 kernels

On 20.01.2023 13:58, vmxevilstar@...il.com wrote:
> Dear Mantainers,
> 
> I am having an issue with my ethernet card.
> It works when the system boots but after around a couple of hours it
> disconnects.
> I tried different ways to get it working without having to reboot but
> nothing else seemed to work.
> Even rebooting doesn't solve the problem since again, after a couple of
> hours, it stops working again.
> I have googled around and found that some people had this same problem
> on older kernels but no solution seemed to apply to this rc nor latest
> stable kernel versions.
> I am probably missing something here.
> The issue happened also with recent stable 6.1.7 and rc kernel
> versions.
> I am actually testing the latest 6.2-rc4 version.
> 
> Following are some data I think might be useful but if you feel I
> neglected to give enough informations and you need more please just ask
> me.
> 
> Here some informations about my system :
> uname -a
> Linux ghost 6.2.0-rc4 #2 SMP PREEMPT_DYNAMIC Tue Jan 17 13:35:46 CET
> 2023 x86_64 GNU/Linux
> 
> gcc --version
> gcc (Debian 12.2.0-14) 12.2.0
> Copyright (C) 2022 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is
> NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> 
> 
> /usr/src# lspci|grep -i net
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125
> 2.5GbE Controller (rev 05)
> 
> description: Ethernet interface
> product: RTL8125 2.5GbE Controller
> vendor: Realtek Semiconductor Co., Ltd.
> physical id: 0
> bus info: pci@...0:02:00.0
> logical name: enp2s0
> version: ff
> serial: b0:25:aa:49:a5:3a
> size: 1Gbit/s
> capacity: 1Gbit/s
> width: 32 bits
> clock: 66MHz
> capabilities: bus_master vga_palette cap_list ethernet physical tp mii
> 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
> configuration: autonegotiation=on broadcast=yes driver=r8169
> driverversion=6.2.0-rc4 duplex=full firmware=rtl8125b-2_0.0.2 07/13/20
> latency=255 link=yes maxlatency=255 mingnt=255 multicast=yes
> port=twisted pair speed=1Gbit/s
> 
> 
> 
> lsmod|grep r8169
> r8169                 110592  0
> mdio_devres            16384  1 r8169
> libphy                200704  3 r8169,mdio_devres,realtek
> 
> the firmware version I am using is linux-firmware-20221214.tar.gz
> 
> 
> Here you can find what happens (dmesg -wT)
> [Fri Jan 20 11:04:32 2023] userif-3: sent link up event.
> 
> [Fri Jan 20 13:19:41 2023] r8169 0000:02:00.0 enp2s0: rtl_chipcmd_cond
> == 1 (loop: 100, delay: 100).
> [Fri Jan 20 13:19:41 2023] r8169 0000:02:00.0 enp2s0: rtl_ephyar_cond
> == 1 (loop: 100, delay: 10).
> [Fri Jan 20 13:19:41 2023] r8169 0000:02:00.0 enp2s0: rtl_ephyar_cond
> == 1 (loop: 100, delay: 10).
> [Fri Jan 20 13:19:41 2023] r8169 0000:02:00.0 enp2s0: rtl_ephyar_cond
> == 1 (loop: 100, delay: 10).
> [Fri Jan 20 13:19:41 2023] r8169 0000:02:00.0 enp2s0: rtl_ephyar_cond
> == 1 (loop: 100, delay: 10).
> [Fri Jan 20 13:19:41 2023] r8169 0000:02:00.0 enp2s0: rtl_ephyar_cond
> == 1 (loop: 100, delay: 10).
> [Fri Jan 20 13:19:41 2023] r8169 0000:02:00.0 enp2s0: rtl_ephyar_cond
> == 1 (loop: 100, delay: 10).
> [Fri Jan 20 13:19:41 2023] r8169 0000:02:00.0 enp2s0:
> rtl_mac_ocp_e00e_cond == 1 (loop: 10, delay: 1000).
> [Fri Jan 20 13:20:17 2023] r8169 0000:02:00.0 enp2s0: rtl_chipcmd_cond
> == 1 (loop: 100, delay: 100).
> [Fri Jan 20 13:20:17 2023] r8169 0000:02:00.0 enp2s0: rtl_ephyar_cond
> == 1 (loop: 100, delay: 10).
> [Fri Jan 20 13:20:17 2023] r8169 0000:02:00.0 enp2s0: rtl_ephyar_cond
> == 1 (loop: 100, delay: 10).
> [Fri Jan 20 13:20:17 2023] r8169 0000:02:00.0 enp2s0: rtl_ephyar_cond
> == 1 (loop: 100, delay: 10).
> [Fri Jan 20 13:20:17 2023] r8169 0000:02:00.0 enp2s0: rtl_ephyar_cond
> == 1 (loop: 100, delay: 10).
> [Fri Jan 20 13:20:17 2023] r8169 0000:02:00.0 enp2s0: rtl_ephyar_cond
> == 1 (loop: 100, delay: 10).
> [Fri Jan 20 13:20:17 2023] r8169 0000:02:00.0 enp2s0: rtl_ephyar_cond
> == 1 (loop: 100, delay: 10).
> [Fri Jan 20 13:20:18 2023] r8169 0000:02:00.0 enp2s0:
> rtl_mac_ocp_e00e_cond == 1 (loop: 10, delay: 1000).
> 

Thanks for the report. rtl_chipcmd_cond is used only during chip reset,
so I guess there's a tx timeout trace in the log before your snippet.

Typical reason is a system ASPM incompatibility. You can try to disable
ASPM in the BIOS, or use the sysfs attributes under
/sys/class/net/<if>/device/link to disable ASPM states. L1.2 is disabled
per default, therefore next one to try is L1.1.


> I would love to provide a patch of any kind but I am afraid I don't
> have enough programming skills.
> 
> Thanks in advance for your time.