Re: [Intel-wired-lan] suspend/resume broken of igc driver broken on 6.12

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 11 Feb 2025 20:20:03 +0200
"Lifshits, Vitaly" <vitaly.lifshits@intel.com> wrote:

> 
> 
> On 2/6/2025 10:09 PM, Stephen Hemminger wrote:
> > On Thu, 6 Feb 2025 15:17:00 +0200
> > "Lifshits, Vitaly" <vitaly.lifshits@intel.com> wrote:
> > 
> >> On 2/6/2025 6:13 AM, Stephen Hemminger wrote:
> >>> On Wed, 5 Feb 2025 12:36:31 +0200
> >>> "Lifshits, Vitaly" <vitaly.lifshits@intel.com> wrote:
> >>>    
> >>>> On 1/31/2025 3:21 AM, Stephen Hemminger wrote:
> >>>>> On Thu, 30 Jan 2025 21:17:30 +0200
> >>>>> "Lifshits, Vitaly" <vitaly.lifshits@intel.com> wrote:
> >>>>>       
> >>>>>> On 1/30/2025 7:11 PM, Stephen Hemminger wrote:
> >>>>>>> I am using:
> >>>>>>>
> >>>>>>> 5a:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-LM (rev 04)
> >>>>>>> 	Subsystem: Intel Corporation Device 0000
> >>>>>>> 	Flags: bus master, fast devsel, latency 0, IRQ 19, IOMMU group 20
> >>>>>>> 	Memory at 6c500000 (32-bit, non-prefetchable) [size=1M]
> >>>>>>> 	Memory at 6c600000 (32-bit, non-prefetchable) [size=16K]
> >>>>>>> 	Capabilities: [40] Power Management version 3
> >>>>>>> 	Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
> >>>>>>> 	Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
> >>>>>>> 	Capabilities: [a0] Express Endpoint, IntMsgNum 0
> >>>>>>> 	Capabilities: [100] Advanced Error Reporting
> >>>>>>> 	Capabilities: [140] Device Serial Number 58-47-ca-ff-ff-7a-98-3d
> >>>>>>> 	Capabilities: [1c0] Latency Tolerance Reporting
> >>>>>>> 	Capabilities: [1f0] Precision Time Measurement
> >>>>>>> 	Capabilities: [1e0] L1 PM Substates
> >>>>>>> 	Kernel driver in use: igc
> >>>>>>> 	Kernel modules: igc
> >>>>>>>
> >>>>>>>
> >>>>>>> Using both Debian testing and my own kernel built from 6.12, the igc
> >>>>>>> driver appears broken after resume.
> >>>>>>
> >>>>>>     From which system state are you resuming?
> >>>>>>      
> >>>>>>>
> >>>>>>> After resuming the device is down and no address present.
> >>>>>>> Attempts to set link up manually fail.
> >>>>>>
> >>>>>> Did you get any errors in the dmesg log?
> >>>>>> What is the firmware version on your device (you can get it by running
> >>>>>> ethtool -i)?
> >>>>>>      
> >>>>>>> If I do rmmod/modprobe of igc it comes back.
> >>>>>>>
> >>>>>>> Doing a bit of bisectting but it is slow going.
> >>>>>>
> >>>>>> Meanwhile, we'll also try to reproduce this issue in our lab.  Could you
> >>>>>> share more details about your system so we can create a similar setup?
> >>>>>
> >>>>> Given that error reported is -ENODEV, might be a generic netdev problem not
> >>>>> just for igc device.
> >>>>>       
> >>>>
> >>>> We weren't able to reproduce this issue on our systems, even though we
> >>>> tried several suspend-resume cycles on different kernels and different
> >>>> systems.
> >>>>
> >>>> However, a few days ago we received a comment in a BZ about an issue
> >>>> similar to yours. In there adding a short delay in igc_resume function
> >>>> https://bugzilla.kernel.org/show_bug.cgi?id=219143
> >>>> https://bugzilla.kernel.org/show_bug.cgi?id=219143#c123
> >>>>
> >>>>
> >>>>
> >>>> Can you try to see if it fixes your issue as well?
> >>>
> >>> I tried the proposed delay and it had no impact.
> >>> Any idea of other things to instrument?
> >>>    
> >>
> >>
> >> Has the adapter worked with a different kernel? Can you try to reproduce
> >> the issue over kernel 6.9?
> >>
> >> Is the LAN cable connected to the igc adapter? Does it maintain link
> >> during suspend?
> >>
> >> Also, I saw that on your board you have three more adapters, I assume
> >> that enp2s0f0np0 and enp2s0f0np1 are i40e adapters. Does this issue also
> >> happen to enp87s0?
> > 
> > This is a new machine, and not sure if it ever worked.
> > I can boot some older distro via USB if that helps.
> 
> Yes, please.
> It might help us in narrowing down the issue.
> 
> > 
> > The LAN cable is always connected (it is a desktop box), and the
> > 10G NIC's are not used; they are connected by a loopback cable and
> > used for DPDK testing occasionally.
> > 
> > It does work in Windows...
> 
> Do you work with Network Manager? If so, is it possible to see if the 
> issue can be reproduced with it disabled?
> 

If network manager is disabled with:
# systemctl stop NetworkManager.service
# systemctl disable NetworkManager.service


Then device persists across suspend/resume.