Comment # 19 on bug 905988 from Benjamin Poirier

(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)?