On Dec 11 01:06, Francois Romieu wrote:
> Corinna Vinschen <vinschen@redhat.com> :
> [...]
> > It's still a bit weird.  On the machines I tested this on, if I disable
> > LanWake and shutdown the machine, I can send, e.g., MagicPackets as much
> > as I like, the machined don't come up.  Isn't it a bit misleading then
> > if ethtool reports that some WoL method is enabled but it doesn't work?
> 
> Of course it is. :o(
> 
> I'm fine with Config5.LanWake changes if you have empirical evidences that
> it helps.
> 
> We have terse - outdated ? - documentation and some hint from
> http://marc.info/?l=linux-netdev&m=137654699802446. I'm unable to figure
> what an/the adequate change could be, especially a low level chance of
> regression one.

I think the problem here is that LanWake only switches off aspects of
the WoL capability which can't be reflected in a reliable way to the
kernel.  That's certainly one reason for the driver to enable/disable
LanWake always in lock-step with PMEnable.

So I wonder if we shouldn't just add some code to rtl_init_one (or
create a new function called from rtl_init_one) which checks the WoL
flags and if the PmConfig and LanWake flags are set inconsistently
(aka "differently") then set them to an equal value, either 0 (no WoL
method enabled) or 1 (any WoL method enabled).

Does that make sense?


Thanks,
Corinna