http://bugzilla.suse.com/show_bug.cgi?id=905988 --- Comment #19 from Benjamin Poirier <bpoirier@suse.com> --- (In reply to Jon Nelson from comment #16)

The patched driver does not output the wol status:

2014-11-27T21:52:44.652923-06:00 linux kernel: [ 8958.665703] r8169 0000:03:00.0 eth0: wol changed by ethtool (5503) 2014-11-27T21:52:44.652940-06:00 linux kernel: [ 8958.665768] r8169 0000:03:00.0 eth0: wol status

:-(

Thanks for testing. That output means that wol is not enabled in any way actually. You can double check that ethtool reports 'd' - disabled. +static void rtl8169_print_wol(struct rtl8169_private *tp) +{ + u32 wolopts = __rtl8169_get_wol(tp); + + netif_info(tp, wol, tp->dev, "wol status %c%c%c%c%c\n", + wolopts & WAKE_PHY ? 'p' : ' ', + wolopts & WAKE_UCAST ? 'u' : ' ', + wolopts & WAKE_MCAST ? 'm' : ' ', + wolopts & WAKE_BCAST ? 'b' : ' ', + wolopts & WAKE_MAGIC ? 'g' : ' '); +} + Perhaps I should have put a 'd' flag like ethtool to make it less confusing...

2014-11-27T21:52:44.652923-06:00 linux kernel: [ 8958.665703] r8169 0000:03:00.0 eth0: wol changed by ethtool (5503)

In this case wol has been disabled. We are looking for a log entry where wol has been enabled spuriously. Can you please look for such a case and supply logs to find out which process is responsible for this (and when)? -- You are receiving this mail because: You are on the CC list for the bug.