On Dec 11 01:06, Francois Romieu wrote: > Corinna Vinschen <vinsc...@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
pgpN4_FLvqZpy.pgp
Description: PGP signature
