sky2 ethernet card don't work after returning from suspension

Bug #1798921 reported by Podesta on 2018-10-20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

[SRU justification]

== Impact ==
Ethernet connection using a SKY2 card stops working after suspend.

== Fix ==
A fix for this landed in v5.0 upstream and was picked up in Xenial via upstream stable but not yet in Bionic and Cosmic. The change simply increases a timeout.

== Testcase ==
Suspend/resume with affected hardware present.

== Risk of Regression ==
Very low as only changing a timeout value in a specific hardware driver.


Bug very similar to #1752772 ( but affecting the sky2 driver instead of r8169.

After system suspend the ethernet connection stops working. The card is still up and the modem can see it is connected, but the card doesn't get an ip address. Ifconfig down/up and restarting network-manager does not solve the issue. Similarly to the other bug, "sudo modprobe sky2 -r" an then "sudo modprobe sky2" solves the issue.


Linux 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

       description: Ethernet interface
       product: 88E8040 PCI-E Fast Ethernet Controller
       vendor: Marvell Technology Group Ltd.
       physical id: 0
       bus info: pci@0000:09:00.0
       logical name: enp9s0
       version: 13
       size: 100Mbit/s
       capacity: 100Mbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=sky2 driverversion=1.30 duplex=full latency=0 link=yes multicast=yes port=twisted pair speed=100Mbit/s
       resources: irq:24 memory:f68fc000-f68fffff ioport:de00(size=256)

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1798921

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: bionic
Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to . Please test the latest v4.19 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.


Changed in linux (Ubuntu):
importance: Undecided → Medium
kris (ski007) wrote :

kernel-bug-exists-upstream :-(


Please try the kernel in

Best regards,
Cristian Aravena Romero (caravena)

kris (ski007) wrote :

I just installed it .... it does not work
there is still an error:
"sky2 ethernet card do not work after returning from suspension"

kris (ski007) wrote :

uname -a
Linux kris-R780 4.15.0-39-generic #42~lp1798921 SMP Wed Oct 24 05:59:26 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

after waking up with the option suspend helps only:
rmmod sky2
modprobe sky2

Kai-Heng Feng (kaihengfeng) wrote :

Please attach the dmesg when the issue happens, thanks!

kris (ski007) wrote :

my dmesg saved on pastebinit

however, the error ends on the line

[ 380.567633] do_IRQ: 3.34 No irq handler for vector

further entries after the option:

rmmod sky2
modprobe sky2

to get internet access and pastebinit services :-)


Podesta (podesta) wrote :

I came in to apologize for not testing the posted kernel before and finally do it. Went on to use the ethernet only since yesterday, and couldn't get the bug anymore, while it happened 100% of the time before.

kris, could you test if you are still getting it with the latest normal ubuntu kernel?

4.15.0-38-generic #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

I'll still try the posted kernel and see if the problem happens again.

Kai-Heng Feng (kaihengfeng) wrote :

Thanks. I'll upstream the change when you confirm it really fixes the issue.

kris (ski007) wrote :

and which kernel is corrected :-)
Now I have :
Linux kris-R780 4.19.1-041901-generic #201811041431 SMP Sun Nov 4 14:33:06 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
the same error........

Podesta (podesta) wrote :

I ran some tests today to try and pinpoint it a little better, and understand why I didn't encounter it when testing a couple days ago. For me, the case seems to be related to the user that suspends.

I couldn't find any difference between the kernel "4.15.0-38-generic #41-Ubuntu" and "4.15.0-39-generic #42~lp1798921", meaning that on my tests, they both happened and didn't happen under the same circumstances.

    * Boot Computer -> login to BOB -> Suspend -> Wake -> login to BOB => NO PROBLEMS.
No matter how many times I tried, as long as I suspended and when woke logged back in to the same user, I never encountered the bug.

    * Boot Computer -> login to BOB -> Suspend -> Wake -> Login to MARY => FAIL.
If when I returned from suspend I logged in to a different user, I always encountered the bug.

    * Boot Computer -> login to BOB -> Suspend -> Wake -> Suspend again -> login to BOB => FAIL.
If when I woke from the first sleep, the pc went back to suspend, and only then I logged back in to BOB, I encountered the bug 100% of the time.

    * Boot Computer -> login to BOB -> Lock screen(change user) -> Login to MARY -> Suspend -> Wake -> Login to BOB => NO PROBLEMS.
Again, once I return from suspend, logging back to the user that 'established the connection' means I don't have any issues.

    * Boot Computer -> login to BOB -> Lock screen(change user) -> Login to MARY -> Suspend -> Wake -> Login to MARY => FAIL.
Now, if I login to a different user, even if it is the user that performed the suspend, I always encountered the bug.

    * The instance that was not clear cut is when I logged out of a user, instead of simply changing users. So for example, login to BOB, suspend, wake, login to BOB, logout, and then go to Mary. I very rarely encountered issues, but it did happen a couple times, so I'm not sure on this point.

One very important thing to note is that when the bug happens, it sticks up no matter what. So, if I encounter the bug, and do the workaround fix with the modprobe command, the bug will happen again in the next suspend, no matter in which circunstance. A reboot restores things to normal.

Not sure if my case is similar to yours kris, but hopefully this bit helps a bit more to pinpoint the issue.

Podesta (podesta) on 2018-11-12
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
description: updated
Kai-Heng Feng (kaihengfeng) wrote :

> * Boot Computer -> login to BOB -> Suspend -> Wake -> login to BOB => NO PROBLEMS.
Then the issue is solve, from kernel's perspective.

> * Boot Computer -> login to BOB -> Suspend -> Wake -> Login to MARY => FAIL.
Under the fail case, can you establish internet connection manually via NetworkManager?

kris (ski007) wrote :

I will say yes, I have three systems
Linux Mint / Xubuntu / Debian (stretch)
Debian (stretch) stable: kernel 4.9.XXX - sky2 / suspend - OK
Linux Mint 18.3 Sylvia: kernel 4.13. XX - sky2 / suspend - OK
Xubuntu 18.04.1 LTS: kernel 4.19.1 - sky2 / suspend - Error
sky2 works OK also on kernel
I think sky2 does not work correctly on kernels above 4.14 ....
but I am not a specialist, maybe others will speak :-)
for now I will still use this fix:

cd /lib/systemd/system-sleep/restore_connection

sleep 5
case $1/$2 in
sudo systemctl restart network-manager.service
modprobe -r sky2
modprobe sky2

Kai-Heng Feng (kaihengfeng) wrote :

Kris, have you tried kernel in #3?

kris (ski007) wrote :

And this is not the same as #7 ?

Kai-Heng Feng (kaihengfeng) wrote :

Please provide dmesg when the issue happens, under kernel in #7.

kris (ski007) wrote :

Here you are #9 :-)

Kai-Heng Feng (kaihengfeng) wrote :

No it's not.

kris (ski007) wrote :

maybe someone else will help with this error ... :-(

Kai-Heng Feng (kaihengfeng) wrote :

The head of your dmesg is "Linux version 4.15.0-39-generic (buildd@lgw01-amd64-054)" so it's not built by me.

kris (ski007) wrote :

:-) ....
I installed the kernel again from the link
the error with me is the same
dmesg :
I'm not testing anymore

kris (ski007) wrote :

I'm now using Debian - everything works OK ?

Kai-Heng Feng (kaihengfeng) wrote :

So your issue happens since commit bc976233a872. Once Debian starts using kernel > 4.14 then the issue will resurface again.

kris (ski007) wrote :

what to do .... if no one can fix it :-)
I know the fix #15
it will be harder for other linux users :-(

I'm running Gentoo with a 4.19.1 kernel on a macbook 3.1. If you want me to revert that git, do bissects, etc, please just ask, I won't be able to run debian/ubuntu kernels.

kris (ski007) wrote :

I'm sorry but it's probably the fault of a particular laptop Samsung R780 :-(
I checked the recurring error on the internet :
[ 380.567633] do_IRQ: 3.34 No irq handler for vector
I applied fix to grub file : pci=nomsi,noaer

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=nomsi,noaer"
update-grub / reboot
and everything works fine ??? :-)
The sky2 ethernet card works well after coming back from the suspension !

but why do not I need this entry on my laptop on Debian with the 4.9.x.x kernel?
I have no idea ...

bam (mybigspam) wrote :

I wonder what performance penalty "pci=nomsi,noaer" would has?

Kai-Heng Feng (kaihengfeng) wrote :

Please attach `sudo lspci -vvnn`.

I'd like to see if it support MSI-X or maskable MSI.

kris (ski007) wrote :

I no longer use the suspend option
I replaced the HDD drive with SSD :-)
if you need a command result from a Samsung R780 laptop
I give it:

Simon (simontipping21) wrote :
Download full text (3.2 KiB)

Would this bug effect WoL functionality?

I've not experienced connectivity problems after resuming from suspend (using power button) but I only log into one account and use a pre-assigned IP address.

Bios and WoL flags are set correctly withing netplan yaml config file but I cannot get the computer to wake using WoL. I can see that the router is sending the magic packet information as well.

This leads to conclude that this bug could be affecting this functionality?

dump of lsci -vvnn:


02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller [11ab:4364] (rev 12)
 Subsystem: ASUSTeK Computer Inc. Motherboard [1043:81f8]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0, Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 24
 Region 0: Memory at fbefc000 (64-bit, non-prefetchable) [size=16K]
 Region 2: I/O ports at d800 [size=256]
 Expansion ROM at fbec0000 [disabled] [size=128K]
 Capabilities: [48] Power Management version 3
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
 Capabilities: [50] Vital Product Data
  Product Name: Marvell Yukon 88E8056 Gigabit Ethernet Controller
  Read-only fields:
   [PN] Part number: Yukon 88E8056
   [EC] Engineering changes: Rev. 1.2
   [MN] Manufacture ID: 4d 61 72 76 65 6c 6c
   [SN] Serial number: AbCdEfG5B6C1B
   [CP] Extended capability: 01 10 cc 03
   [RV] Reserved: checksum good, 9 byte(s) reserved
  Read/write fields:
   [RW] Read-write area: 121 byte(s) free
 Capabilities: [5c] MSI: Enable+ Count=1/1 Maskable- 64bit+
  Address: 00000000fee01004 Data: 4025
 Capabilities: [e0] Express (v1) Legacy Endpoint, MSI 00
  DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
   ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
  DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
   RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
   MaxPayload 128 bytes, MaxReadReq 512 bytes
  DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend+
  LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <256ns, L1 unlimited
   ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
  LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk+
   ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
  LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
 Capabilities: [100 v1] Advanced Error Reporting
  UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
  UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
  UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
  CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
  CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
  AERCap: First Error Pointer: ...


Richard (richard1024) wrote :

I have the same problem.

I am on "Linux Mint 18.2 Sonya". Upgrading to Kernel 4.15.0-39.42~16.04.1 showed the same problem. I reverted to a 4.13 kernel for this reason.

$ lshw -class network
WARNUNG: Sie sollten dieses Programm mit Systemverwalterrechten (root) ausführen.
  *-network DEAKTIVIERT
       Beschreibung: Kabellose Verbindung
       Produkt: BCM4312 802.11b/g LP-PHY
       Hersteller: Broadcom Corporation
       Physische ID: 0
       Bus-Informationen: pci@0000:0c:00.0
       Logischer Name: wlp12s0
       Version: 01
       Seriennummer: 00:26:5e:33:a9:6d
       Breite: 64 bits
       Takt: 33MHz
       Fähigkeiten: bus_master cap_list ethernet physical wireless
       Konfiguration: broadcast=yes driver=wl0 driverversion= (r587334) latency=0 multicast=yes wireless=IEEE 802.11
       Ressourcen: irq:17 memory:f69fc000-f69fffff
       Beschreibung: Ethernet interface
       Produkt: 88E8040 PCI-E Fast Ethernet Controller
       Hersteller: Marvell Technology Group Ltd.
       Physische ID: 0
       Bus-Informationen: pci@0000:09:00.0
       Logischer Name: enp9s0
       Version: 13
       Seriennummer: 00:25:64:4a:26:00
       Größe: 100Mbit/s
       Kapazität: 100Mbit/s
       Breite: 64 bits
       Takt: 33MHz
       Fähigkeiten: bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd autonegotiation
       Konfiguration: autonegotiation=on broadcast=yes driver=sky2 driverversion=1.30 duplex=full ip= latency=0 link=yes multicast=yes port=twisted pair speed=100Mbit/s
       Ressourcen: irq:24 memory:f68fc000-f68fffff ioport:de00(Größe=256)

Kai-Heng Feng (kaihengfeng) wrote :

So there are three different issue:

Podesta's (original bug reporter): increase D3 delay can workaround the issue.
Kris': non-maskable MSI issued IRQ before device resume, we probably need a DMI quirk table to let affected platforms use INTx.
WoL: Does it ever work in previous kernel versions?

Anyway please file a new bugs for separate issues. I'll upstream a fix for Podesta's issue as he's the original bug reporter.

Richard (richard1024) wrote :

For me, it works with any 4.13 kernel.

Richard (richard1024) wrote :

Sorry, didn't realize what was meant. I don't use WoL, only suspend (manually or by closing the lid). Resume works for me with the 4.13 kernels Mint provided so far. All of the 4.15 kernels I tried so far didn't work.

I've also filed for this issue.

Kai-Heng Feng (kaihengfeng) wrote :

Sorry for the late reply. Sent a patch:

Stefan Bader (smb) wrote :

This actually came to Xenial via upstream stable 4.4.176. This went into v5.0-rc8 upstream, so it is by now released on devel/disco. I am adding additional nominations to act as reminders for those releases.

Changed in linux (Ubuntu Xenial):
importance: Undecided → Medium
status: New → Fix Committed
Stefan Bader (smb) on 2019-03-14
Changed in linux (Ubuntu):
status: Confirmed → Fix Released
Brad Figg (brad-figg) wrote :

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed-xenial'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-xenial
kris (ski007) wrote :

I can not check the kernel v5.0-rc8
because I have other errors regarding the nvidia graphics card and the system does not start


As Stefan mentioned on comment #38, this fix is for now available only on xenial/linux 4.4 kernels, which received the patch as part of an stable upstream update. So only this kernel needs verification for now.

Launchpad Janitor (janitor) wrote :
Download full text (26.1 KiB)

This bug was fixed in the package linux - 4.4.0-145.171

linux (4.4.0-145.171) xenial; urgency=medium

  * linux: 4.4.0-145.171 -proposed tracker (LP: #1821724)

  * linux-generic should depend on linux-base >=4.1 (LP: #1820419)
    - [Packaging] Fix linux-base dependency

linux (4.4.0-144.170) xenial; urgency=medium

  * linux: 4.4.0-144.170 -proposed tracker (LP: #1819660)

  * Packaging resync (LP: #1786013)
    - [Packaging] resync getabis
    - [Packaging] update helper scripts
    - [Packaging] resync retpoline extraction

  * C++ demangling support missing from perf (LP: #1396654)
    - [Packaging] fix a mistype

  * CVE-2019-9213
    - mm: enforce min addr even if capable() in expand_downwards()

  * CVE-2019-3460
    - Bluetooth: Check L2CAP option sizes returned from l2cap_get_conf_opt

  * Xenial update: 4.4.176 upstream stable release (LP: #1818815)
    - net: fix IPv6 prefix route residue
    - vsock: cope with memory allocation failure at socket creation time
    - hwmon: (lm80) Fix missing unlock on error in set_fan_div()
    - net: Fix for_each_netdev_feature on Big endian
    - net: Add header for usage of fls64()
    - tcp: tcp_v4_err() should be more careful
    - net: Do not allocate page fragments that are not skb aligned
    - tcp: clear icsk_backoff in tcp_write_queue_purge()
    - vxlan: test dev->flags & IFF_UP before calling netif_rx()
    - net: stmmac: Fix a race in EEE enable callback
    - net: ipv4: use a dedicated counter for icmp_v4 redirect packets
    - x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32
    - mfd: as3722: Handle interrupts on suspend
    - mfd: as3722: Mark PM functions as __maybe_unused
    - net/x25: do not hold the cpu too long in x25_new_lci()
    - mISDN: fix a race in dev_expire_timer()
    - ax25: fix possible use-after-free
    - Linux 4.4.176

  * sky2 ethernet card don't work after returning from suspension
    (LP: #1798921) // Xenial update: 4.4.176 upstream stable release
    (LP: #1818815)
    - sky2: Increase D3 delay again

  * Xenial update: 4.4.175 upstream stable release (LP: #1818813)
    - drm/bufs: Fix Spectre v1 vulnerability
    - staging: iio: adc: ad7280a: handle error from __ad7280_read32()
    - ASoC: Intel: mrfld: fix uninitialized variable access
    - scsi: lpfc: Correct LCB RJT handling
    - ARM: 8808/1: kexec:offline panic_smp_self_stop CPU
    - dlm: Don't swamp the CPU with callbacks queued during recovery
    - x86/PCI: Fix Broadcom CNB20LE unintended sign extension (redux)
    - powerpc/pseries: add of_node_put() in dlpar_detach_node()
    - serial: fsl_lpuart: clear parity enable bit when disable parity
    - ptp: check gettime64 return code in PTP_SYS_OFFSET ioctl
    - staging:iio:ad2s90: Make probe handle spi_setup failure
    - staging: iio: ad7780: update voltage on read
    - ARM: OMAP2+: hwmod: Fix some section annotations
    - modpost: validate symbol names also in find_elf_symbol
    - perf tools: Add Hygon Dhyana support
    - soc/tegra: Don't leak device tree node reference
    - f2fs: move dir data flush to write checkpoint process
    - f2fs: fix wrong return value of f2fs_acl_create
    - sunvdc: Do not spin in an infin...

Changed in linux (Ubuntu Xenial):
status: Fix Committed → Fix Released
tags: added: verification-done-xenial
removed: verification-needed-xenial
Stefan Bader (smb) on 2019-04-08
Changed in linux (Ubuntu Bionic):
importance: Undecided → Medium
Changed in linux (Ubuntu Cosmic):
importance: Undecided → Medium
Stefan Bader (smb) on 2019-04-08
Changed in linux (Ubuntu Bionic):
status: New → Confirmed
Changed in linux (Ubuntu Cosmic):
status: New → Confirmed

Hey there, I'm having this issue with a Mint 19 (bionic) installation and two Marvell 88E8053 NICs. Logged in, press the power button or the Suspend menu, computer goes to sleep. When awoken from the power button, "Network cable is disconnected".

I found the workaround of "sudo modprobe -r sky2; modprobe -i sky2" to work quite nicely.

$ uname -rms
Linux 4.15.0-47-generic x86_64

Tested with:

* linux-image-4.15.0-47-generic/bionic-updates,bionic-security,now 4.15.0-47.50 amd64
* linux-image-4.18.0-17-generic/bionic-updates,bionic-security,now 4.18.0-17.18~18.04.1 amd64

If you need any more details, please feel free to be as analytical as possible ;)

Stefan Bader (smb) on 2019-04-08
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers