I found on this machine(https://certification.canonical.com/hardware/202304-31462/) which uses the same card RTL8168fp/RTL8117 (XID 54b, DASH: disabled), I suppose this is a single hardware issue, but not 100% sure.
I also tested against several ThinkStation/ThinkCentre machines with RTL8168fp/RTL8117 (XID 54a, DASH: disabled), they all works fine. Test output for 202304-31462: Results generated by fwts: Version V24.07.00 (2024-07-30 03:13:27). Some of this work - Copyright (c) 1999 - 2023, Intel Corp. All rights reserved. Some of this work - Copyright (c) 2010 - 2023, Canonical. Some of this work - Copyright (c) 2016 - 2023, IBM. Some of this work - Copyright (c) 2017 - 2023, ARM Ltd. This test run on 23/09/24 at 17:38:41 on host Linux ubuntu 6.8.0-44-generic #44~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Aug 22 15:00:55 UTC 2 x86_64. Command: "fwts --s3-multiple=5 s3". Running tests: s3. s3: Sleep suspend/resume test. -------------------------------------------------------------------------------- Test 1 of 1: Sleep suspend/resume test. s2idle cycle 1 of 5 Detecting the power method. Response to CanSuspend is yes User allowed to execute the CanSuspend action Using logind as the default power method. Requesting Suspend action Skipping the minimum delay (0) and using a 3 seconds delay instead s2idle duration = 32. wakeup source name: "00:00" wakeup event was signaled. pm-action returned 0 after 32 seconds. Spent 84.32% of 32s in hardware sleep state Suspend/Resume Timings: Suspend: 0.729 seconds. Resume: 1.430 seconds. s2idle cycle 2 of 5 Using logind as the default power method. Requesting Suspend action Skipping the minimum delay (0) and using a 3 seconds delay instead s2idle duration = 32. wakeup source name: "00:00" wakeup event was signaled. pm-action returned 0 after 32 seconds. Spent 87.83% of 32s in hardware sleep state Suspend/Resume Timings: Suspend: 0.660 seconds. Resume: 1.423 seconds. s2idle cycle 3 of 5 Using logind as the default power method. Requesting Suspend action Skipping the minimum delay (0) and using a 3 seconds delay instead s2idle duration = 31. wakeup source name: "00:00" wakeup event was signaled. pm-action returned 0 after 31 seconds. Spent 89.12% of 31s in hardware sleep state Suspend/Resume Timings: Suspend: 0.667 seconds. Resume: 1.422 seconds. s2idle cycle 4 of 5 Using logind as the default power method. Requesting Suspend action Skipping the minimum delay (0) and using a 3 seconds delay instead s2idle duration = 32. wakeup source name: "00:00" wakeup event was signaled. pm-action returned 0 after 32 seconds. Spent 87.73% of 32s in hardware sleep state Suspend/Resume Timings: Suspend: 0.721 seconds. Resume: 1.424 seconds. s2idle cycle 5 of 5 Using logind as the default power method. Requesting Suspend action Skipping the minimum delay (0) and using a 3 seconds delay instead s2idle duration = 31. wakeup source name: "00:00" wakeup event was signaled. pm-action returned 0 after 31 seconds. Spent 88.96% of 31s in hardware sleep state Suspend/Resume Timings: Suspend: 0.713 seconds. Resume: 1.415 seconds. Completed s2idle cycle(s) PASSED: Test 1, No kernel log errors detected. PASSED: Test 1, No PM related suspend issues detected. PASSED: Test 1, No device errors detected. PASSED: Test 1, No kernel oopses detected. PASSED: Test 1, No kernel WARN_ON warnings detected. PASSED: Test 1, No s2idle errors detected. PASSED: Test 1, Found no errors doing 5 suspend/resume cycle(s). PASSED: Test 1, All suspends took less than 15.00 seconds. PASSED: Test 1, All resumes took less than 15.00 seconds. ================================================================================ 9 passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. ================================================================================ 9 passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. Test Failure Summary ================================================================================ Critical failures: NONE High failures: NONE Medium failures: NONE Low failures: NONE Other failures: NONE Test |Pass |Fail |Abort|Warn |Skip |Info | ---------------+-----+-----+-----+-----+-----+-----+ s3 | 9| | | | | | ---------------+-----+-----+-----+-----+-----+-----+ Total: | 9| 0| 0| 0| 0| 0| ---------------+-----+-----+-----+-----+-----+-----+ -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed-hwe-6.8 in Ubuntu. https://bugs.launchpad.net/bugs/2080454 Title: NIC(r8169) didn't link up after resuming from suspend Status in linux-signed-hwe-6.8 package in Ubuntu: New Bug description: [Summary] During the SRU testing, I found a hp laptop always timeout after suspend test, after checking I found that the NIC didn't link up. Part of journal log as follows: Sep 12 11:13:01 ubuntu kernel: PM: suspend entry (s2idle) ... ... Sep 12 11:13:10 ubuntu kernel: PM: suspend exit ... Sep 12 11:13:14 ubuntu kernel: r8169 0000:02:00.1 enp2s0f1: PCI error (cmd = 0x0407, status_errs = 0x0000) [Expected result] SRU test can continue after suspend test. [Actual result] SRU test times out and NIC is down. [Additional information] Following are the DUTs that are impacted. https://certification.canonical.com/hardware/202304-31463/ ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.8.0-44-generic 6.8.0-44.44~22.04.1 ProcVersionSignature: Ubuntu 6.8.0-44.44~22.04.1-generic 6.8.12 Uname: Linux 6.8.0-44-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.6 Architecture: amd64 CasperMD5CheckMismatches: ./preseed/project.cfg CasperMD5CheckResult: fail Date: Thu Sep 12 11:16:43 2024 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-stella-jammy-amd64-20230920-537 InstallationDate: Installed on 2024-09-11 (0 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - pc-stella-jammy-amd64-20230920-537 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: linux-signed-hwe-6.8 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-6.8/+bug/2080454/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
