On Tue, 11 Feb 2025 20:20:03 +0200 "Lifshits, Vitaly" <vitaly.lifsh...@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.lifsh...@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.lifsh...@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.lifsh...@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? > Yes Debian uses Network Manager, but disabling it might not be possible.
