PDA

View Full Version : [SOLVED] Suspend with Intel Network adapter broken: PM: Device 0000:00:19.0 failed to suspend



helge000
19th August 2013, 11:10 PM
Hi,
just wanted to post a solution for a problem I have recently with Fedora 19 and the kernel-3.10.X line.

Symptom: Notebook was not able to sleep and did wake up immediately. The problem seems to be with the Intel network adapter driver, e1000e. It looks like an already suspended device is suspended again, this does not work.

If you encounter the problem, you will find something like this in your logs:

pci_pm_suspend(): e1000_suspend+0x0/0x20 [e1000e] returns -2
dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns -2
PM: Device 0000:00:19.0 failed to suspend async: error -2
PM: Some devices failed to suspend

A workaround is to unload the kernel module e1000e prior to sleep. One can either do this manually if encountered (lame!) or let systemd do the job. Just create this file and make it executable:



$ cat /usr/lib/systemd/system-sleep/e1000e-probe.sh

#!/bin/bash
# /usr/lib/systemd/system-sleep/e1000e-probe.sh
# handles e1000e driver suspend problems:
# pci_pm_suspend(): e1000_suspend+0x0/0x20 [e1000e] returns -2
# dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns -2
# PM: Device 0000:00:19.0 failed to suspend async: error -2
# PM: Some devices failed to suspend


case "$1" in
"pre") rmmod e1000e
;;
"post") modprobe e1000e
;;
esac

This will unload the driver before sleep and load it again when waking up.

mikeymop
21st August 2013, 06:51 AM
I believe I may be experiencing this issue. My desktop will wake immediately after suspend, I believe it may be the xhci driver, however this could be the cause too as I use an Intel NIC. What log did you check in your post?

stevea
21st August 2013, 08:09 AM
Try a
lsmod
to see what drivers are loaded.


The log in post #1 is probably ...

dmesg | less

george_toolan
21st August 2013, 08:38 AM
Please check /var/log/pm-suspend.log

helge000
21st August 2013, 12:03 PM
This depends on your log facility! If Fedora 19 did shut down syslog already (I do not use it anymore since F18) you may have to use journalctl. It works on Fedora 18/19 no matter what.

Here the procedure:
1. Wait until you have the issue. Then verify it by suspending to RAM manually; you should see the screen going dark two times (systemd tires to suspend twice it seems)
2. run from console: su -c "journalctl -f -p 3" - This will print the journal to console with syslog priority err and below as they are logged.
3. Suspend manually again. You should see the PM: error mentioned in my post.
4. Run su -c "rmmod e1000e" and try to suspend again. If suspend now works again, my script can help you.

Hope this helps!

mikeymop
22nd August 2013, 08:28 AM
Please check /var/log/pm-suspend.log

I tried as root, pm-suspend.log and the boot logs dont exist as reported by the terminal emulator.



1. Wait until you have the issue. Then verify it by suspending to RAM manually; you should see the screen going dark two times (systemd tires to suspend twice it seems)

Hope this helps!

I may have a different issue then, I'll try this tomorrow but I dont see the flicker you're talking about. It's weird, it performs a flawless suspend but then it wakes. Is WoL enabled by default?

My motherboard (Asus (P8z77i-deluxe) is UEFI but doesn't support secure boot. I get the message from Fedora reminding my it's disabled. (I dont see Plymouth either, which makes me side but thats besides the point) Could this be holding back suspend?

adaawgg
24th August 2013, 03:54 PM
Hello! I'm having a very similar issue myself. My laptop fails to sleep, and in the logs, I have the following:


Aug 24 09:57:10 localhost.localdomain kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Aug 24 09:57:10 localhost.localdomain kernel: ata3.00: failed command: STANDBY IMMEDIATE
Aug 24 09:57:10 localhost.localdomain kernel: [123B blob data]
Aug 24 09:57:10 localhost.localdomain kernel: ata3.00: status: { DRDY }
Aug 24 09:57:10 localhost.localdomain kernel: ata3: hard resetting link
Aug 24 09:57:10 localhost.localdomain kernel: ata3: nv: skipping hardreset on occupied port
Aug 24 09:57:10 localhost.localdomain kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Aug 24 09:57:10 localhost.localdomain kernel: ata3.00: configured for UDMA/100
Aug 24 09:57:10 localhost.localdomain kernel: ata3.00: device reported invalid CHS sector 0
Aug 24 09:57:10 localhost.localdomain kernel: ata3: EH complete
Aug 24 09:57:10 localhost.localdomain kernel: sd 2:0:0:0: [sda] START_STOP FAILED
Aug 24 09:57:10 localhost.localdomain kernel: sd 2:0:0:0: [sda]
Aug 24 09:57:10 localhost.localdomain kernel: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Aug 24 09:57:10 localhost.localdomain kernel: sd 2:0:0:0: [sda]
Aug 24 09:57:10 localhost.localdomain kernel: Sense Key : Aborted Command [current] [descriptor]
Aug 24 09:57:10 localhost.localdomain kernel: sd 2:0:0:0: [sda]
Aug 24 09:57:10 localhost.localdomain kernel: Add. Sense: No additional sense information
Aug 24 09:57:10 localhost.localdomain kernel: dpm_run_callback(): scsi_bus_suspend+0x0/0x40 returns 134217730
Aug 24 09:57:10 localhost.localdomain kernel: PM: Device 2:0:0:0 failed to suspend async: error 134217730
Aug 24 09:57:10 localhost.localdomain kernel: PM: Some devices failed to suspend


By the way, my system does not a log at this address, either /var/log/pm-suspend.log. Just figured I'd state that.

And also, here is my run of lsmod

bnep 19704 2
bluetooth 362314 7 bnep
nf_conntrack_netbios_ns 12665 0
nf_conntrack_broadcast 12527 1 nf_conntrack_netbios_ns
ipt_MASQUERADE 12880 1
ip6table_nat 13015 1
nf_nat_ipv6 13213 1 ip6table_nat
ip6table_mangle 12700 1
ip6t_REJECT 12939 2
nf_conntrack_ipv6 18782 24
nf_defrag_ipv6 34589 1 nf_conntrack_ipv6
iptable_nat 13011 1
nf_nat_ipv4 13199 1 iptable_nat
nf_nat 25743 5 ipt_MASQUERADE,nf_nat_ipv4,nf_nat_ipv6,ip6table_na t,iptable_nat
iptable_mangle 12695 1
nf_conntrack_ipv4 14808 20
nf_defrag_ipv4 12673 1 nf_conntrack_ipv4
xt_conntrack 12760 42
nf_conntrack 86430 11 nf_conntrack_netbios_ns,ipt_MASQUERADE,nf_nat,nf_n at_ipv4,nf_nat_ipv6,xt_conntrack,ip6table_nat,nf_c onntrack_broadcast,iptable_nat,nf_conntrack_ipv4,n f_conntrack_ipv6
ebtable_filter 12827 0
ebtables 30758 1 ebtable_filter
ip6table_filter 12815 1
ip6_tables 26808 3 ip6table_filter,ip6table_mangle,ip6table_nat
arc4 12608 2
b43 387760 0
bcma 40755 1 b43
mac80211 566043 1 b43
cfg80211 465187 2 b43,mac80211
snd_hda_codec_conexant 56945 1
hp_wmi 13945 0
sparse_keymap 13584 1 hp_wmi
rfkill 21694 5 cfg80211,hp_wmi,bluetooth
snd_hda_intel 43836 4
snd_hda_codec 179124 2 snd_hda_codec_conexant,snd_hda_intel
snd_hwdep 17650 1 snd_hda_codec
snd_seq 60752 0
powernow_k8 24264 0
snd_seq_device 14136 1 snd_seq
kvm_amd 59945 0
kvm 422809 1 kvm_amd
snd_pcm 98071 2 snd_hda_codec,snd_hda_intel
snd_page_alloc 18268 2 snd_pcm,snd_hda_intel
joydev 17332 0
edac_core 56744 0
snd_timer 28698 2 snd_pcm,snd_seq
k8temp 12978 0
edac_mce_amd 22349 0
snd 75292 16 snd_hwdep,snd_timer,snd_hda_codec_conexant,snd_pcm ,snd_seq,snd_hda_codec,snd_hda_intel,snd_seq_devic e
ssb 65906 1 b43
forcedeth 67429 0
soundcore 14491 1 snd
nv_tco 13564 0
mmc_core 112285 2 b43,ssb
i2c_nforce2 13173 0
binfmt_misc 17431 1
uinput 17625 0
nouveau 989091 3
mxm_wmi 12865 1 nouveau
i2c_algo_bit 13257 1 nouveau
drm_kms_helper 50210 1 nouveau
ttm 80402 1 nouveau
ata_generic 12910 0
pata_acpi 13038 0
drm 272504 5 ttm,drm_kms_helper,nouveau
sata_nv 27745 2
pata_amd 14129 0
i2c_core 34242 5 drm,drm_kms_helper,i2c_algo_bit,nouveau,i2c_nforce 2
wmi 18697 3 hp_wmi,mxm_wmi,nouveau
video 19052 1 nouveau


I tried the solution offered in the first post, and it obviously didn't work. From what I've looked at (which I could be completely wrong), my issue looks to deal with suspending the disk, not a network adapter.

Does anyone have any suggestions?

Thanks!

mikeymop
26th August 2013, 08:40 PM
$ lsmod | grep 'e1000e'
e1000e 250230 0
ptp 18372 1 e1000e
[mikey@comp ~]$

I noticed the module is in fact loaded. And the NIC when in Windows wake the computer from suspend instantly, I applied a driver update and disabled Wake On Lan in Windows. Both of which simultaneously seems to have solved the issue.

I booted fedora again, ran

$modprobe -r e1000e

I waited for my nic in the top right to disconnect and suspended. My computer still woke immediately from suspend. So I believe either e1000e module isn't the cause of my issue, or I have multiple things keeping my computer from suspending.

kldixon
27th August 2013, 03:24 PM
I have just built a new machine with an Intel MB, DH87RL, and had this problem when shutting down. The machine powered down then switched on again. I found this on Intel's site:
http://communities.intel.com/message/203690#203690
I stopped the problem by switching off WOL in the BIOS. There is an option called "Wakeon LAN from S4/S5" which I set to "Stay off". I thought WOL required a magic packet to operate so perhaps there is a hardware bug in intel's controller or some bit is not being set by e1000e.