Wakes from S3 in a few seconds unless WIndows has been run

[Boris Gjenero]

I'm running 64-bit Ubuntu 15.04 on a Gigabyte GA-P35-DS3R rev 1.0 motherboard with BIOS F13. I also have 32-bit Windows 7 SP1. If power was fully cut, including standby power, and Windows has not been run since then, Ubuntu will quickly wake from S3 sleep without any apparent reason. Procedure to reproduce:

1. Shut down computer normally from the operating system.
2. When computer appears off, cut power either via the switch on the back or by unplugging it.
3. Wait some time. 10 seconds is probably enough and a minute should be 100% certain.
4. Boot directly into Ubuntu. It's okay to boot into Ubuntu via the Windows 7 boot menu. Do not actually boot into Windows itself though; if you do that you must restart at step 1.
5. Initiate S3 sleep. I have tried both of these with the same results:
dbus-send --print-reply --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.Suspend boolean:true
sudo sh -c "echo mem > /sys/power/state"
6. Wait. The system should wake up within a few seconds, and certainly in less than a minute. The delay varies.

The only problem is that the system won't stay sleeping. Everything works fine after the system wakes. Repeated attempts to sleep give the same result.

I have disabled everything in /proc/acpi/wakeup using the following in /etc/rc.local:
sed -n '/enabled/s,\([^\t]\+\)\s.*$,echo \1 > /proc/acpi/wakeup,p' /proc/acpi/wakeup | sh
I confirm that it appears disabled before and after sleep.

I have also disabled all wakeup files in sys (found via sudo find /sys -iname wakeup -type f), and it didn't help.

The logs don't seem to show a wakeup reason.

If I boot into Windows 7 and then boot into Linux, this problem stops happening. Shutting down from either operating system or pressing the reset button does not cause the problem to reoccur. It only reoccurs if standby power has been cut. I am assuming that Linux fails to perform some initialization which Windows performs, and that initialization persists as long as standby power is available. I am assuming this is a kernel bug because it occurs even if I use "echo mem > /sys/power/state" to enter sleep.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: linux-image-3.19.0-15-generic 3.19.0-15.15
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: bgjenero 2280 F.... pulseaudio
CurrentDesktop: X-Cinnamon
Date: Wed Apr 29 10:39:49 2015
HibernationDevice: RESUME=UUID=a44c3385-e1ba-4456-91ec-be27c892ff11
InstallationDate: Installed on 2012-01-19 (1196 days ago)
InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
MachineType: Gigabyte Technology Co., Ltd. P35-DS3R
ProcFB:

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic root=UUID=e59328d8-57ee-4106-aa49-41ceffea8161 ro
RelatedPackageVersions:
 linux-restricted-modules-3.19.0-15-generic N/A
 linux-backports-modules-3.19.0-15-generic N/A
 linux-firmware 1.143
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UpgradeStatus: Upgraded to vivid on 2015-04-24 (5 days ago)
dmi.bios.date: 06/19/2009
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F13
dmi.board.name: P35-DS3R
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF13:bd06/19/2009:svnGigabyteTechnologyCo.,Ltd.:pnP35-DS3R:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnP35-DS3R:rvr:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: P35-DS3R
dmi.sys.vendor: Gigabyte Technology Co., Ltd.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.0 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'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1-rc1-vivid/

[Boris Gjenero (boris-gjenero)]

I can reproduce this with v4.1-rc1-vivid. I had to uninstall nvidia-340-updates because the DKMS module failed to build and boot hung while it was installed. So, I was using nouveau for my GeForce 8600GT PCI express graphics card.

I can't reproduce it if not running X, or running X, twm and xterm or GNOME terminal. However, if I run Google Chrome in addition to that, I can reproduce it. Also, I can always reproduce it when using Openbox or Cinnamon.

Successful sleep in Linux (without an unexpected wakeup) does not prevent future wakeups when conditions change.

[penalvch (penalvch)]

Boris Gjenero, could you please provide the missing information following https://wiki.ubuntu.com/DebuggingKernelSuspend ?

[Boris Gjenero (boris-gjenero)]

I solved the problem. This was wake on LAN. When I ran "sudo ethtool eth0" the output included:
        Supports Wake-on: pumbg
        Wake-on: ug
From the ethtool man page:
              u Wake on unicast messages
              g Wake on MagicPacket™

This was wake on unicast messages. "Wake-on: ug" is the default both with the r8169 driver that's included in the kernel and with the r8168-dkms package which presumably contains the driver from Realtek. I guess the BIOS sets it up this way. I see no BIOS options relating to wake on LAN. I disabled wake on LAN via the Advanced settings in Device Manager in Windows, and that was persisting until all power including standby power was cut. I am now disabling WOL with the following line in /etc/rc.local:
ethtool -s eth0 wol d
I also tried "ethtool -s eth0 wol g" which only wakes on magic packet and I didn't get an unexpected wakeup.

Enabling wake on unicast messages by default is ridiculous. I guess this may be the fault of my BIOS. I'm not sure if there's anything Linux could do about that automatically.

I just wish Linux would tell me what's the wake reason! If I saw something telling me this was wake on LAN I would have spent much less time figuring this out!

Here's "sudo lspci -v" info about the ethernet controller, 10ec:8168:
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
 Subsystem: Gigabyte Technology Co., Ltd Motherboard
 Flags: bus master, fast devsel, latency 0, IRQ 29
 I/O ports at d000 [size=256]
 Memory at f9000000 (64-bit, non-prefetchable) [size=4K]
 [virtual] Expansion ROM at f8000000 [disabled] [size=128K]
 Capabilities: [40] Power Management version 2
 Capabilities: [48] Vital Product Data
 Capabilities: [50] MSI: Enable+ Count=1/2 Maskable- 64bit+
 Capabilities: [60] Express Endpoint, MSI 00
 Capabilities: [84] Vendor Specific Information: Len=4c <?>
 Capabilities: [100] Advanced Error Reporting
 Capabilities: [12c] Virtual Channel
 Capabilities: [148] Device Serial Number 00-00-00-00-10-ec-81-68
 Capabilities: [154] Power Budgeting <?>
 Kernel driver in use: r8169

My suspend tests were using this command to initiate suspend, running as a normal user:
dbus-send --print-reply --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.Suspend boolean:true

The attached /proc/acpi/wakeup file is in the state used during my most recent testing. I am disabling everything there via /etc/rc.local, but that didn't solve the problem.

I never got any matches in my resume trace, just magic numbers. Anyways, that data should only be relevant if there is a lockup while going to sleep or resuming.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]