© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
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-
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=
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.