On Wed, 5 Feb 2025 12:36:31 +0200 "Lifshits, Vitaly" <[email protected]> wrote:
> On 1/31/2025 3:21 AM, Stephen Hemminger wrote: > > On Thu, 30 Jan 2025 21:17:30 +0200 > > "Lifshits, Vitaly" <[email protected]> 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?
