> Tobias Diedrich wrote:
> > Tobias Diedrich wrote:
> > > So my BIOS is not as borked as I thought and it should be possible
> > > to wake up the machine even with platform. Further debugging will
> > > have to wait until at least next weekend though (maybe longer)...
> >
> > Or maybe it doesn't have to wait, I was just too curious:
> >
> > Summary first: I got platform mode to work!
> >
> > After grepping and reading through kernel/power/disk.c and
> > (rather obfuscated) drivers/acpi/.* code, and reading up on
> > ACPI _GPE (General Purpose Event?), and having a look at my DSDT I
> > noticed two things:
> >
> > 1) The network controllers are assigned to their own _GPE bits(pins?):
> > |[...]
> > | Scope (\_GPE)
> > | {
> > |[...]
> > | Method (_L0B, 0, NotSerialized)
> > | {
> > | Notify (\_SB.PCI0.MMAC, 0x02)
> > | }
> > |
> > | Method (_L0A, 0, NotSerialized)
> > | {
> > | Notify (\_SB.PCI0.MAC1, 0x02)
> > | }
> > |[...]
> >
> > 2) drivers/acpi/sleep/proc.c registers a 'wakeup' file:
> > | proc_create("wakeup", S_IFREG | S_IRUGO | S_IWUSR,
> > | acpi_root_dir, &acpi_system_wakeup_device_fops);
> >
> > And I then remembered that someone said in
> >
http://bugzilla.kernel.org/show_bug.cgi?id=8381
> > it works for him if he writes $MAGICVALUE into a proc file.
> >
> > And yes, if I write 'MMAC' and 'MAC1' into /proc/acpi/wakeup, then
> > wake-on-lan works even in platform mode.
> >
> > So...
> > AFAICS this bit of setup magic should not be required, because:
> >
> > 1) /proc/acpi/wakeup knows which pci device is associated to each GPE bit
> > |ranma@melchior:~$ cat /proc/acpi/wakeup
> > |Device S-state Status Sysfs node
> > |HUB0 S5 disabled pci:0000:00:06.0
> > |XVR0 S5 disabled
> > |XVR1 S5 disabled pci:0000:00:0e.0
> > |XVR2 S5 disabled
> > |XVR3 S5 disabled
> > |XVR4 S5 disabled
> > |XVR5 S5 disabled pci:0000:00:0a.0
> > |UAR1 S5 disabled pnp:00:09
> > |PS2K S4 disabled pnp:00:0b
> > |USB0 S4 disabled pci:0000:00:02.0
> > |USB2 S4 disabled pci:0000:00:02.1
> > |AZAD S5 disabled pci:0000:00:06.1
> > |MMAC S5 enabled pci:0000:00:08.0
> > |MAC1 S5 enabled pci:0000:00:09.0
> > (values after manually enabling MMAC and MAC1)
> >
> > 2) kernel/power/disk.c calls hibernation_ops->enter(), which is
> > acpi_suspend_enter, which calls acpi_enable_wakeup_device, which
> > sets up GPE wakup bits. This _should_ take care of enabling MMAC
> > and MAC1 automatically, but apparently does not work correctly at
> > some point.
> >
> > I guess someone more knowledgable in ACPI stuff should have a look
> > at this.
>
> Any reason this patch hasn't made it into the kernel so far?
>
http://lists.laptop.org/pipermail/devel/2007-April/004691.html
>
> (Ok, I tried getting it to apply to a current kernel, but it
> a splodes (reboots instead of powering off, last message on the
> serial console is "ACPI handle has no context!", see below))
>
> The platform_enable_wakeup() hook is still there, but unused.
> AFAICS this patch should solve the "'ethtool -s eth0 wol g' doesn't
> suffice, I also have to write magic values into /proc/acpi/wakeup"
> issue.
