The issue should be fixed in 6.8.0-44.44 by below commit

commit 27e70aa72937bcfd08ffc10727ad315f9763e6ac
Author: Hui Wang <hui.w...@canonical.com>
Date:   Thu Jul 18 16:57:16 2024 +0800

    e1000e: move force SMBUS near the end of enable_ulp function
    
    BugLink: https://bugs.launchpad.net/bugs/2073358
    
    The commit 861e8086029e ("e1000e: move force SMBUS from enable ulp
    function to avoid PHY loss issue") introduces a regression on
    PCH_MTP_I219_LM18 (PCIID: 0x8086550A). Without the referred commit, the
    ethernet works well after suspend and resume, but after applying the
    commit, the ethernet couldn't work anymore after the resume and the
    dmesg shows that the NIC link changes to 10Mbps (1000Mbps originally):
    
        [   43.305084] e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 10 Mbps 
Full Duplex, Flow Control: Rx/Tx
    
    Without the commit, the force SMBUS code will not be executed if
    "return 0" or "goto out" is executed in the enable_ulp(), and in my
    case, the "goto out" is executed since FWSM_FW_VALID is set. But after
    applying the commit, the force SMBUS code will be ran unconditionally.
    
    Here move the force SMBUS code back to enable_ulp() and put it
    immediately ahead of hw->phy.ops.release(hw), this could allow the
    longest settling time as possible for interface in this function and
    doesn't change the original code logic.
    
    The issue was found on a Lenovo laptop with the ethernet hw as below:
    00:1f.6 Ethernet controller [0200]: Intel Corporation Device [8086:550a]
    (rev 20).
    
    And this patch is verified (cable plug and unplug, system suspend
    and resume) on Lenovo laptops with ethernet hw: [8086:550a],
    [8086:550b], [8086:15bb], [8086:15be], [8086:1a1f], [8086:1a1c] and
    [8086:0dc7].
    
    Fixes: 861e8086029e ("e1000e: move force SMBUS from enable ulp function to 
avoid PHY loss issue")
    Signed-off-by: Hui Wang <hui.w...@canonical.com>
    Acked-by: Vitaly Lifshits <vitaly.lifsh...@intel.com>
    Tested-by: Naama Meir <naamax.m...@linux.intel.com>
    Reviewed-by: Simon Horman <ho...@kernel.org>
    Reviewed-by: Paul Menzel <pmen...@molgen.mpg.de>
    Signed-off-by: Tony Nguyen <anthony.l.ngu...@intel.com>
    Tested-by: Zhang Rui <rui.zh...@intel.com>
    Signed-off-by: Jacob Keller <jacob.e.kel...@intel.com>
    Link: 
https://lore.kernel.org/r/20240528-net-2024-05-28-intel-net-fixes-v1-1-dc8593d2b...@intel.com
    Signed-off-by: Jakub Kicinski <k...@kernel.org>
    (cherry picked from commit bfd546a552e140b0a4c8a21527c39d6d21addb28)
    Signed-off-by: Aaron Ma <aaron...@canonical.com>
    Acked-by: Thibault Ferrante <thibault.ferra...@canonical.com>
    Acked-by: Noah Wager <noah.wa...@canonical.com>
    Acked-by: Andrei Gherzan <andrei.gher...@canonical.com>
    Signed-off-by: Roxana Nicolescu <roxana.nicole...@canonical.com>

-- 
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/2078656

Title:
  NIC speed down to 10 Mbps after resuming from suspend

Status in linux-signed-hwe-6.8 package in Ubuntu:
  New

Bug description:
  [Summary]

  During the SRU testing, I found at least 2 DUTs always timeout after
  suspend test, after checking I found that both of them only detect 10
  Mbps speed on their NIC and can't get IP from DHCP.

  Part of journal log as follows:
  Sep 02 10:55:00 ubuntu kernel: PM: suspend entry (s2idle)
  ...
  ...
  Sep 02 10:55:11 ubuntu kernel: PM: suspend exit
  ....
  Sep 02 10:55:15 ubuntu kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 
10 Mbps Full Duplex, Flow Control: None

  [Expected result]

  SRU test can continue after suspend test and network speed should be
  1000 Mbps.

  [Actual result]

  SRU test times out and network speed down to 10 Mbps.

  [Additional information]

  Following are the DUTs that are impacted.
  https://certification.canonical.com/hardware/202312-33185/
  https://certification.canonical.com/hardware/202312-32380/

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: linux-image-6.8.0-40-generic 6.8.0-40.40~22.04.3
  ProcVersionSignature: Ubuntu 6.8.0-40.40~22.04.3-generic 6.8.12
  Uname: Linux 6.8.0-40-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu82.6
  Architecture: amd64
  CasperMD5json:
   {
     "result": "skip"
   }
  Date: Mon Sep  2 11:58:59 2024
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-jammy-amd64-20220504-33+jellyfish-aron-14+X120
  InstallationDate: Installed on 2024-08-20 (12 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - 
somerville-jammy-amd64-20220504-33
  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/2078656/+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

Reply via email to