I recently installed Debian 10.6 on my desktop computer, and discovered that I have a problem with my ethernet network connection after waking the computer from sleep mode. Specifically, after waking the computer from sleep mode, I have no ethernet network connection. After rebooting the computer, the connection is restored. My Linux kernel version is 4.19.0-11-amd64. Any ideas how to solve this strange problem?

Following the suggestion from A.B, here is the output from lspci -k | grep -A3 Ethernet:

02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8071 PCI-E Gigabit Ethernet Controller (rev 16)
    Subsystem: Acer Incorporated [ALI] 88E8071 PCI-E Gigabit Ethernet Controller
    Kernel driver in use: sky2
    Kernel modules: sky2
03:00.0 FireWire (IEEE 1394): JMicron Technology Corp. IEEE 1394 Host Controller

I don't know if it helps, but I have now also added some relevant lines from running dmesg below: After waking from sleep:

[ 7544.632643] ata3.00: configured for UDMA/133
[ 7544.935093] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[ 7544.937339] sky2 0000:02:00.0 enp2s0: enabling interface
[ 7544.937528] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[ 7547.437266] do_IRQ: 2.34 No irq handler for vector

After rebooting:

[   19.698910] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[   19.701050] sky2 0000:02:00.0 enp2s0: enabling interface
[   19.701183] IPv6: ADDRCONF(NETDEV_UP): enp2s0: link is not ready
[   22.187327] sky2 0000:02:00.0 enp2s0: Link is up at 1000 Mbps, full duplex, flow control both
[   22.187359] IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes ready
[   53.492928] fuse init (API version 7.27)
[   60.534172] rfkill: input handler disabled
  • 1
    It could also involve the specific NIC hardware and its driver. You should provide the NIC model and driver. Perhaps from lspci -k|grep -A3 Ethernet, or if the device is named eth0 (please adapt) ethtool -i eth0.
    – A.B
    Oct 3, 2020 at 11:30
  • 1
    Please use ethtool instead. You missed the additional lines (-A3) from lspci giving also the driver in use
    – A.B
    Oct 3, 2020 at 11:35
  • 1
    run ethtool as root (or with sudo)
    – A.B
    Oct 3, 2020 at 11:36
  • 1
    I can see various fixes related to suspend for various pc models using sky2. Check: git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/… . Anyway if I were you I'd try if using a newer kernel would fix the problem. Using backports you could install linux-image-5.8.0-0.bpo.2-amd64-unsigned (probably requires UEFI not in secure mode). Beside this I don't have any better idea.
    – A.B
    Oct 3, 2020 at 11:47
  • 1
    check this: askubuntu.com/questions/1029620/…
    – A.B
    Oct 3, 2020 at 15:25

1 Answer 1


It turned out that the problem in my case had to do with the following line in the output from dmesg:

[ 7547.437266] do_IRQ: 2.34 No irq handler for vector

This problem is addressed in the following post on askubuntu: https://askubuntu.com/questions/1029620/ubuntu-18-04-lts-sky2-ethernet-stops-working-after-system-resume-from-suspend#comment1956841_1094045. Many thanks to user A.B for pointing out this post to me!

I did the following to solve the problem:

  • Add the line GRUB_CMDLINE_LINUX_DEFAULT="quiet splash sky2.disable_msi=1" to the file /etc/default/grub
  • Run the command update-grub. Note: I had to do su - root rather than just su in order to be able to run update-grub.
  • Reboot the computer.
  • I've started getting this problem (with a dmesg line of the form: __common_interrupt: 1.33 No irq handler for vector) since upgrading from Devuan 3 "Chimaera" with a 5.10 kernel to Devuan 4 "Daedalus" with a 6.1 one. forums.linuxmint.com/viewtopic.php?t=287759 gives some useful details which matched mine: system goes to sleep and when it wakes up the wired network does not work and the workaround was - as root - service networking stop; rmmod sky2; modprobe sky2; service networking start. I am just trying adding disable_msi=1 to a (new file) /etc/modules-load.d/sjy2.conf...
    – SlySven
    Oct 26, 2023 at 20:41
  • I should have mentioned that the file (sky2.conf, there was a typo in the previous comment and I didn't spot it in time to correct) would be needed for that sequence of four superuser commands to have worked without disable_msi=1 being given as an additional argument to the modprobe one! Anyhow this seems to fix things. 8-)
    – SlySven
    Oct 26, 2023 at 21:13
  • This kml thread gives more insight as well: lore.kernel.org/all/… particularly examining the output from cat /proc/interrupts | grep eth to see if the option has taken effect and the interrupt is of type IO-APIC (OK) or PCI_MSI (BAD).
    – SlySven
    Oct 26, 2023 at 21:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .