Wake On Lan device semantics
I am working on getting WOL to work on sky2 (and then skge). But in the process I noticed that the semantics of WOL seems to be device dependent. I assume that WOL should work when device is suspended. But some drivers also support WOL when the device is down (or even removed). Now I know some distro's like Ubuntu take down and then remove every network device on suspend. That's their problem, if they don't want to use suspend as intended because they want to handle broken hardware, that's their problem. It doesn't seem like a good idea for a network device to wake the system if it is down. Maybe if the kernel fully supported dormant, maybe, but when device is down it shouldn't impact the system. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
On Fri, 03 Nov 2006 15:44:13 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke It seems odd because that means you can never make a device fully deaf. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
On Fri, 03 Nov 2006 15:44:13 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke Interestingly it looks like e100 is one of the ones that only wakes from suspend (not when down). -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
Stephen Hemminger wrote: I am working on getting WOL to work on sky2 (and then skge). But in the process I noticed that the semantics of WOL seems to be device dependent. I assume that WOL should work when device is suspended. But some drivers also support WOL when the device is down (or even removed). [...] It doesn't seem like a good idea for a network device to wake the system if it is down. Maybe if the kernel fully supported dormant, maybe, but when device is down it shouldn't impact the system. You seem to be muddling device, driver, and system together. The purpose of WOL is being able to turn on a system remotely, if it is in a power-off or sleep state. So, if the system is -on- and the interface is down and/or driver is unloaded, are you saying WOL is a problem somehow? Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 03 Nov 2006 18:51:25 -0500 The purpose of WOL is being able to turn on a system remotely, if it is in a power-off or sleep state. So, if the system is -on- and the interface is down and/or driver is unloaded, are you saying WOL is a problem somehow? Stephen is saying that if you down an interface, it should disable that WoL functionality. I guess you can argue that, like IP addresses, this WoL thing is an attribute of the system. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
On Fri, 03 Nov 2006 16:02:30 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 03 Nov 2006 18:51:25 -0500 The purpose of WOL is being able to turn on a system remotely, if it is in a power-off or sleep state. So, if the system is -on- and the interface is down and/or driver is unloaded, are you saying WOL is a problem somehow? Stephen is saying that if you down an interface, it should disable that WoL functionality. I guess you can argue that, like IP addresses, this WoL thing is an attribute of the system. Looking harder. The semantic needs to be WOL is okay if driver is loaded and device is up or down. But the default for WOL should be disabled until enabled by ethtool (or parameter). -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
David Miller wrote: From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 03 Nov 2006 18:51:25 -0500 The purpose of WOL is being able to turn on a system remotely, if it is in a power-off or sleep state. So, if the system is -on- and the interface is down and/or driver is unloaded, are you saying WOL is a problem somehow? Stephen is saying that if you down an interface, it should disable that WoL functionality. Many distros down the interface on poweroff, a state from which WOL is often used, so we don't want this. I guess you can argue that, like IP addresses, this WoL thing is an attribute of the system. Yeah, it's definitely a system state. When the magic packet arrives, the WOL wire on the motherboard is tickled, turning the machine on. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 03 Nov 2006 19:42:49 -0500 David Miller wrote: I guess you can argue that, like IP addresses, this WoL thing is an attribute of the system. Yeah, it's definitely a system state. When the magic packet arrives, the WOL wire on the motherboard is tickled, turning the machine on. Ok, and Stephen seems to agree now too on this point. I think there is merit to Stephen's assertion that WoL should be off by default. It allows remote entities to do something to your computer. I'm happy to hear counter-arguments, of course :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
Stephen Hemminger wrote: On Fri, 03 Nov 2006 15:44:13 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke It seems odd because that means you can never make a device fully deaf. sure you can, just turn off WoL and e1000 will really shutdown (at least, I hope :)) Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
On Fri, 03 Nov 2006 17:36:45 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: On Fri, 03 Nov 2006 15:44:13 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke Interestingly it looks like e100 is one of the ones that only wakes from suspend (not when down). that would be a bug, I'll have to get that checked especially after the latest changes to it. Sorry, my bad my test machine was not setup properly. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
Stephen Hemminger wrote: On Fri, 03 Nov 2006 15:44:13 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke Interestingly it looks like e100 is one of the ones that only wakes from suspend (not when down). that would be a bug, I'll have to get that checked especially after the latest changes to it. Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
Stephen Hemminger wrote:
On Fri, 03 Nov 2006 17:36:45 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
On Fri, 03 Nov 2006 15:44:13 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
It doesn't seem like a good idea for a network device to wake the system
if it is down.
before suspend existed this was the only useful case for WoL. Why does it not seem a
good idea to wake up a machine that was shutdown (and thus the interface `downed`) ?
Auke
Interestingly it looks like e100 is one of the ones that only wakes from
suspend (not when down).
that would be a bug, I'll have to get that checked especially after the latest changes
to it.
Sorry, my bad my test machine was not setup properly.
I don't blame you, WoL is one of the hardest features to get right, especially with all
the various e100{,0} hardware and options that influence it (manageability, eeproms, etc).
On top of that there's this blob called BIOS messing it all up after a
powercycle :)
Cheers,
Auke
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
Stephen Hemminger wrote: On Fri, 03 Nov 2006 16:02:30 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 03 Nov 2006 18:51:25 -0500 The purpose of WOL is being able to turn on a system remotely, if it is in a power-off or sleep state. So, if the system is -on- and the interface is down and/or driver is unloaded, are you saying WOL is a problem somehow? Stephen is saying that if you down an interface, it should disable that WoL functionality. I guess you can argue that, like IP addresses, this WoL thing is an attribute of the system. Looking harder. The semantic needs to be WOL is okay if driver is loaded and device is up or down. But the default for WOL should be disabled until enabled by ethtool (or parameter). Since this is enabled already in the BIOSes for most systems (or disabled, and switcheable by the user), I'd say we can let the driver handle the default (on for most cards) already. The BIOS can also handle a WoL call after a (long) powerfailure, before the OS boots, so disabling it in the OS would be quite useless in that case: the BIOS would override it anyway. Doesn't sound like a problem you can solve in the driver layer... Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
