netdev - Re: 4-port ASMedia/RealTek RTL8125 2.5Gbps NIC freezes whole system

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]

Date:   Sat, 25 Feb 2023 09:04:15 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     fk1xdcio@...k.com
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: 4-port ASMedia/RealTek RTL8125 2.5Gbps NIC freezes whole system

On 25.02.2023 00:52, fk1xdcio@...k.com wrote:
> On 2023-02-24 15:21, Heiner Kallweit wrote:
>> On 24.02.2023 15:37, fk1xdcio@...k.com wrote:
>>> I'm having problems getting this 4-port 2.5Gbps NIC to be stable. I have tried on multiple different physical systems both with Xeon server and i7 workstation chipsets and it behaves the same way on everything. Testing with latest Arch Linux and kernels 6.1, 6.2, and 5.15. I'm using the kernel default r8169 driver.
> ...
>>> "SSU-TECH" (generic/counterfeit?) 4-port 2.5Gbps PCIe x4 card
>>>   ASMedia ASM1812 PCIe switch (driver: pcieport)
>>>   RTL8125BG x4 (driver: r8169)
> ...
>> The network driver shouldn't be able to freeze the system. You can test whether vendor driver r8125 makes a difference.
>> This should provide us with an idea whether the root cause is at a lower level.
> 
> Thanks for the suggestion. The official RealTek r8125-9.011.00 driver won't build on new kernels but I tried with LTS kernel 5.15.94.
> 
> I tried using the various parameters available on the r8125 module, including full debug=16, but nothing changed.
> 
> Using the r8125 driver gives different errors. Error D3cold to D0 (used to be D3hot) and then additional new Ethernet errors:
> 
> 3,1276,295280722,-;pcieport 0000:04:02.0: can't change power state from D3cold to D0 (config space inaccessible)
>  SUBSYSTEM=pci
>  DEVICE=+pci:0000:04:02.0
> 3,1277,295481184,-;pcieport 0000:04:00.0: can't change power state from D3cold to D0 (config space inaccessible)
>  SUBSYSTEM=pci
>  DEVICE=+pci:0000:04:00.0
> 3,1278,295982345,-;enp7s0: cmd = 0xff, should be 0x07 \x0a.
> 3,1279,296082571,-;enp7s0: pci link is down \x0a.
> 3,1280,296132687,-;enp8s0: cmd = 0xff, should be 0x07 \x0a.
> 3,1281,296232919,-;enp8s0: pci link is down \x0a.
> 3,1282,296303082,-;enp9s0: cmd = 0xff, should be 0x07 \x0a.
> 3,1283,296403314,-;enp9s0: pci link is down \x0a.
> 3,1284,296453431,-;enp10s0: cmd = 0xff, should be 0x07 \x0a.
> 3,1285,296553661,-;enp10s0: pci link is down \x0a.
> 3,1286,298147344,-;enp7s0: cmd = 0xff, should be 0x07 \x0a.
> 3,1287,298247572,-;enp7s0: pci link is down \x0a.
> 3,1288,298307717,-;enp8s0: cmd = 0xff, should be 0x07 \x0a.
> 
> I don't know what "cmd = 0xff" is referring to. Is this a command directly to the Ethernet chipset?

cmd is a chipset register and value 0xff indicates that it's not accessible.
To me it looks like the issue is somewhere on PCIe level.