wake-on-lan

wake-on-lan

[Joseph Dunn]

I'm trying to get wake-on-lan working for my media box.  However, I'm
running into a problem.  When I halt the machine (shutdown -h) I cannot
wake it.  However, if the machine is unplugged, then plugged back in,
*then* I can wake it.  The lights on the ethernet card will only glow
when the machine is off (i.e. card can wake the machine) when I unplug
the power and plug it back in.  I did find that however software
suspend 2 shuts down the machine does leave it in a wakable state.

So, one option is to hibernate the machine instead of shutting down,
but thats not a great solution.  Also, I have a desktop machine that
has a similar problem.  The wake on alarm in the BIOS cannot wake the
machine if linux performed the last shutdown.  It looks to me like
linux leaves the machine in a deeper sleep state than even plugging it
in for the first time.

I tried to go into the code where the sleep state is hard coded and
mess with it. I edited poweroff.c and changed the two hardcoded lines
referring to S5 to S4.  No affect.  Just to make sure that I was really
calling that code during shutdown I changed it to S0, and the machine
remained on (in S0 state I believe).  By the way, I also tried S3 there
and found that I couldn't wake using the network card in any case.

The machines in question are running Fedora Core 4, but with my own
custom kernels.  The kernels are vanilla for the most part, but are
patched with software suspend and a couple drivers.  I'm sure this is
probably something simple, but it doesnt look like I'm going to trip
over the solution, so does anyone have any suggestions?

-Joe Dunn

RE: wake-on-lan

[Brown, Len]

>When I halt the machine (shutdown -h) I cannot
>wake it.  However, if the machine is unplugged, then plugged back in,
>*then* I can wake it. 

WOL can be done a couple of ways.

If it is implemented using ACPI GPE's, then
you need to find a string (unfortunately, they're arbitrary)
in /proc/acpi/wakeup that looks like your device and echo that
string into the file to toggle between enabled and disabled.

Only Power/Sleep/LID buttons are enabled for wakeup by default.

Note that this I/F is temporary -- the ability of
a device to wake the system should really be a property
of that device in the /sys tree.

cheers,
-Len

Re: wake-on-lan

[Karol Kozimor]

Thus wrote Brown, Len:
> >When I halt the machine (shutdown -h) I cannot
> >wake it.  However, if the machine is unplugged, then plugged back in,
> >*then* I can wake it. 
> 
> WOL can be done a couple of ways.
> 
> If it is implemented using ACPI GPE's, then
> you need to find a string (unfortunately, they're arbitrary)
> in /proc/acpi/wakeup that looks like your device and echo that
> string into the file to toggle between enabled and disabled.
> 
> Only Power/Sleep/LID buttons are enabled for wakeup by default.
> 
> Note that this I/F is temporary -- the ability of
> a device to wake the system should really be a property
> of that device in the /sys tree.

Note also that there are very few explicit calls to pci_enable_wake() in
the whole tree. Linux doesn't set the PME-Enable bit properly, which
apparently results in WOL either working or not working. My understanding
is that the final outcome depends on what BIOS does to the card during
POST. Please see http://bugme.osdl.org/show_bug.cgi?id=3801 for a weird 
example.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: wake-on-lan

[Adam Belay]

On Fri, Jan 20, 2006 at 06:16:35AM +0100, Karol Kozimor wrote:
> Thus wrote Brown, Len:
> > >When I halt the machine (shutdown -h) I cannot
> > >wake it.  However, if the machine is unplugged, then plugged back in,
> > >*then* I can wake it. 
> > 
> > WOL can be done a couple of ways.
> > 
> > If it is implemented using ACPI GPE's, then
> > you need to find a string (unfortunately, they're arbitrary)
> > in /proc/acpi/wakeup that looks like your device and echo that
> > string into the file to toggle between enabled and disabled.
> > 
> > Only Power/Sleep/LID buttons are enabled for wakeup by default.
> > 
> > Note that this I/F is temporary -- the ability of
> > a device to wake the system should really be a property
> > of that device in the /sys tree.
> 
> Note also that there are very few explicit calls to pci_enable_wake() in
> the whole tree. Linux doesn't set the PME-Enable bit properly, which
> apparently results in WOL either working or not working. My understanding
> is that the final outcome depends on what BIOS does to the card during
> POST. Please see http://bugme.osdl.org/show_bug.cgi?id=3801 for a weird 
> example.

I'm in the process of overhauling the PCI layer's power management event
support.  Basically, I'd like to catch ACPI GPE events and then walk the
device tree in thier corresponding location to see if PME is set.  If so
a function like ->wake() will be called for the device driver that owns
the triggered device.  This should allow for even runtime PME usage.  I'm
expecting to have a patch available for the PCI end of these changes soon.

Thanks,
Adam

Re: wake-on-lan

[Karol Kozimor]

Thus wrote Adam Belay:
> > Note also that there are very few explicit calls to pci_enable_wake() in
> > the whole tree. Linux doesn't set the PME-Enable bit properly, which
> > apparently results in WOL either working or not working. My understanding
> > is that the final outcome depends on what BIOS does to the card during
> > POST. Please see http://bugme.osdl.org/show_bug.cgi?id=3801 for a weird 
> > example.
> I'm in the process of overhauling the PCI layer's power management event
> support.  Basically, I'd like to catch ACPI GPE events and then walk the
> device tree in thier corresponding location to see if PME is set.  If so

Ouch. Registering a notify handler against the device's node is not enough?
AFAIR, the spec requires devices that triggered wake-up to be notified and
most DSDTs I've seen do it in one way or another (usually through _WAK).

> a function like ->wake() will be called for the device driver that owns
> the triggered device.  This should allow for even runtime PME usage.  I'm
> expecting to have a patch available for the PCI end of these changes soon.

What point is calling this when we're already up?

Obviously, I haven't seen the whole picture, but from what I know we
already have a .enable_wake callback that is ignored by both the core code
and the drivers. Perhaps extending this callback with platform hooks to
enable the corresponding GPE (die, /proc/acpi/wakeup, die!) and making sure
it actually is called would suffice?

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: wake-on-lan

[Satoru Takeuchi]

Hi, Joseph

At Sun, 8 Jan 2006 10:45:13 -0700,
Joseph Dunn wrote:
> 
> I'm trying to get wake-on-lan working for my media box.  However, I'm
> running into a problem.  When I halt the machine (shutdown -h) I cannot
> wake it.  However, if the machine is unplugged, then plugged back in,
> *then* I can wake it.  The lights on the ethernet card will only glow
> when the machine is off (i.e. card can wake the machine) when I unplug
> the power and plug it back in.  I did find that however software
> suspend 2 shuts down the machine does leave it in a wakable state.

How about this patch?

Thanks,

Satoru Takeuchi

To enable wakeup GPEs, acpi_enable_wakeup_device() has to be called.
But current ACPI subssytem doesn't call this function at the shutdown
time.
This patch fixes it.

Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>

 drivers/acpi/sleep/poweroff.c |    1 +
 drivers/acpi/sleep/wakeup.c   |    2 ++
 2 files changed, 3 insertions(+)

Index: linux-2.6.16-rc1/drivers/acpi/sleep/poweroff.c
===================================================================
--- linux-2.6.16-rc1.orig/drivers/acpi/sleep/poweroff.c	2006-01-03 12:21:10.000000000 +0900
+++ linux-2.6.16-rc1/drivers/acpi/sleep/poweroff.c	2006-01-20 09:47:42.000000000 +0900
@@ -47,6 +47,7 @@
 	/* acpi_sleep_prepare(ACPI_STATE_S5) should have already been called */
 	printk("%s called\n", __FUNCTION__);
 	local_irq_disable();
+	acpi_enable_wakeup_device(ACPI_STATE_S5);
 	/* Some SMP machines only can poweroff in boot CPU */
 	acpi_enter_sleep_state(ACPI_STATE_S5);
 }
Index: linux-2.6.16-rc1/drivers/acpi/sleep/wakeup.c
===================================================================
--- linux-2.6.16-rc1.orig/drivers/acpi/sleep/wakeup.c	2006-01-20 12:04:41.000000000 +0900
+++ linux-2.6.16-rc1/drivers/acpi/sleep/wakeup.c	2006-01-20 12:05:40.000000000 +0900
@@ -48,6 +48,7 @@
 	}
 	spin_unlock(&acpi_device_lock);
 }
+#endif
 
 /**
  * acpi_enable_wakeup_device - enable wakeup devices
@@ -100,6 +101,7 @@
 	spin_unlock(&acpi_device_lock);
 }
 
+#ifdef CONFIG_ACPI_SLEEP
 /**
  * acpi_disable_wakeup_device - disable devices' wakeup capability
  *	@sleep_state:	ACPI state

Re: wake-on-lan

[Adam Belay]

On Fri, Jan 20, 2006 at 07:50:45AM +0100, Karol Kozimor wrote:
> Thus wrote Adam Belay:
> > > Note also that there are very few explicit calls to pci_enable_wake() in
> > > the whole tree. Linux doesn't set the PME-Enable bit properly, which
> > > apparently results in WOL either working or not working. My understanding
> > > is that the final outcome depends on what BIOS does to the card during
> > > POST. Please see http://bugme.osdl.org/show_bug.cgi?id=3801 for a weird 
> > > example.
> > I'm in the process of overhauling the PCI layer's power management event
> > support.  Basically, I'd like to catch ACPI GPE events and then walk the
> > device tree in thier corresponding location to see if PME is set.  If so
> 
> Ouch. Registering a notify handler against the device's node is not enough?
> AFAIR, the spec requires devices that triggered wake-up to be notified and
> most DSDTs I've seen do it in one way or another (usually through _WAK).

Sure, there are a lot of requirements on the ACPI end.  We also need to call
_DSW or _PSW (if it's available) when preparing a PCI device for wakeup.
> 
> > a function like ->wake() will be called for the device driver that owns
> > the triggered device.  This should allow for even runtime PME usage.  I'm
> > expecting to have a patch available for the PCI end of these changes soon.
> 
> What point is calling this when we're already up?

I think you're defining a scope that is too narrow for wake events.
Remember that they can be enabled during S0 (and there are many good
reasons to do so).  In this case, a device is not going to turn on by
itself as ->resume will never be called.  Rather, the driver will need
to evaluate the wake event and determine the proper course of action.  

> 
> Obviously, I haven't seen the whole picture, but from what I know we
> already have a .enable_wake callback that is ignored by both the core code
> and the drivers. Perhaps extending this callback with platform hooks to
> enable the corresponding GPE (die, /proc/acpi/wakeup, die!) and making sure
> it actually is called would suffice?

Yes, I'd like to use platform hooks.  The API on the PCI end might look
like this: (in psuedo-code)

pci_arm_wakeup(struct pci_dev *dev,
	       struct power_state *lowest_state_we_might_enter,
	       struct system_state *target_system_suspend_state)
{
	pci_enable_pme();
	enable_platform_wakeup();
}

pci_disarm_wakeup(struct pci_dev *dev)
{
	disable_platform_wakeup();
	pci_disable_pme();
}

pci_enable_wake() would be deprecated.

Regards,
Adam