System immediately waking from sleep (suspend to RAM) with no user intervention.

English Hardware
#1

This problem started after a fresh install of 13.2 (new root, kept existing /home).

When the system is placed in ‘sleep’ (suspend to ram) the system closes down, apparently correctly… then, immediately resumes.

There have been no hardware, bios (apart from subsequent testing), power management or screensaver changes since running 13.1, which behaved correctly.

For what it’s worth here is the section of log file for the suspend to ram, followed by the immediate (unwanted) resume.

http://paste.opensuse.org/31874780

I’ve no idea what is waking this up. I’ve tried disabling all wakeup options in the system bios, but to no avail.

Any ideas… ?

#2

This will probably require a bug report to resolve, but maybe these are worth reporting here too

cat /sys/bus/usb/devices/*/power/wakeup

cat /var/log/Xorg.0.log|grep boot

lsmod

*They might reveal some problematic parameter or hardware clue

#3

Thanks. – As follows:

paul@Orion-14:~$ cat /sys/bus/usb/devices/*/power/wakeup
disabled
disabled
disabled
disabled
disabled
disabled
disabled
paul@Orion-14:~$

paul@Orion-14:~$ cat /var/log/Xorg.0.log | grep boot
     7.112] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.6-2-desktop root=UUID=e09082b3-18a3-4be0-ab74-f2a0109ceebe quiet lang=en_GB resume=/dev/disk/by-uuid/08a4ff75-8318-40cf-b78b-b7049064dfb5 splash=silent quiet showopts libata.force=noncq
     8.297] (--) NVIDIA(0):     ViewSonic VA926 Series (DFP-0) (boot, connected)
paul@Orion-14:~$

paul@Orion-14:~$ lsmod
Module                  Size  Used by
fuse                  100461  2
af_packet              40034  2
cfg80211              547052  0
rfkill                 26772  1 cfg80211
nvidia_uvm             39162  0
nvidia              10565309  40 nvidia_uvm
joydev                 17344  0
ppdev                  17671  0
snd_hda_codec_realtek    80983  1
snd_hda_codec_generic    77129  1 snd_hda_codec_realtek
snd_hda_intel          34475  3
snd_hda_controller     35103  1 snd_hda_intel
snd_hda_codec         151970  4 snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller
snd_hwdep              13602  1 snd_hda_codec
snd_pcm               116857  3 snd_hda_codec,snd_hda_intel,snd_hda_controller
powernow_k8            32309  0
kvm                   501446  0
snd_timer              33609  1 snd_pcm
snd                    87947  13 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
serio_raw              13434  0
pcspkr                 12718  0
edac_core              66387  0
edac_mce_amd           22578  0
k8temp                 12990  0
wacom                  67184  0
soundcore              15047  2 snd,snd_hda_codec
sp5100_tco             13999  0
i2c_piix4              22166  0
r8169                  75790  0
drm                   335594  3 nvidia
mii                    13934  1 r8169
parport_pc             41414  0
parport                46395  2 ppdev,parport_pc
shpchp                 32951  0
processor              40484  1 powernow_k8
dm_mod                111114  0
uas                    27255  0
usb_storage            62302  1 uas
sr_mod                 22416  0
cdrom                  60734  1 sr_mod
ata_generic            12923  0
pata_atiixp            13279  0
ohci_pci               13570  0
wmi                    19193  0
button                 13971  0
sg                     40630  0
paul@Orion-14:~$

If I knew what I was looking for it may mean something to me … :\

If there are no other responses after a day or two I’ll file a bug report as you suggested.

#4

Nothing strikes me as odd with the requested output. The usb-related output was to do with looking for anything that might be enabled to generate wakeup events. With the grub output. I was looking for ACPI-related parameters. However, your log definitely reports unusual behaviour with

2014-11-17T18:36:35.660751+00:00 Orion-14 kernel:  1289.869829] Broke affinity for irq 16
2014-11-17T18:36:35.660754+00:00 Orion-14 kernel:  1289.869868] Broke affinity for irq 19
2014-11-17T18:36:35.660756+00:00 Orion-14 kernel:  1289.869882] Broke affinity for irq 22
2014-11-17T18:36:35.660758+00:00 Orion-14 kernel:  1289.869884] Broke affinity for irq 42

so a bug report might be needed to help chase this down.

#5

OK - Thanks :slight_smile:

I’ve just finished trying a few things… I’m guessing there’s maybe something about this hardware that 13.2 doesn’t like.

I have just replaced the two SSDs this machine normally runs on with a single HDD that already had a ‘virgin’ install of 13.1 on it.

Suspend/resume works as expected, as I had no problems with this on 13.1

I then did a complete fresh install of 13.2 to that HDD, formatting both root and home. After completion of the install suspend to RAM appears to work correctly in as much as it does not resume immediately ‘by itself’ … however, it won’t resume at all lol! I simply get a blank screen, the ‘Caps Lock’ and ‘Scroll Lock (?)’ LED on the keyboard are flashing. A hard reset is the only way out… (Why the behaviour would be different I have no idea.)

So yes, a bug report is probably in order.

#6

Bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=905988

#7

From above bug report…

Caused by Wake on Lan

Now ‘back to normal’ after

 ethtool -s $DEVICE wol d
#8

ethtool -s $DEVICE wol d

doesn’t survive a re-boot

Solution now is either:

Remove package ‘WOL’ (possibly not installed by default on 13.1, hence no problem then - anyone able to check?)

or

YaST2 -> Network Settings -> Select Network Device -> Hardware Tab - set “wol d” as ethtool option. (If using Network Manager, temporarily change to wicked to enable making the change).