Tobias Diedrich wrote:
> 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.
Ok, after another long debugging session I finally found out the
reason for the immediate reboot (after finding the place that
suspends the serial console (drivers/pnp) and disabling that suspend
path):
The system is woken up by USB activity! (Optical mouse, anyone?)
Lo and behold:
drivers/usb/core/hcd-pci.c tries it's best to activate 'wake on
usb', which I didn't know since it apparently also never worked.
However, after applying the 'use platform_enable_wakeup'-patch,
not only forcedeth wake starts working, also usb wake.
If I prevent usb wake:
|echo disabled > /sys/devices/pci0000\:00/0000\:00\:02.0/power/wakeup'
|echo disabled > /sys/devices/pci0000\:00/0000\:00\:02.1/power/wakeup'
And then hibernate in platform mode, the immediate reboot is gone
and waking up using magic packets works fine even without setting up
/proc/acpi/wakeup first.
Maybe I should try hooking mouse and keyboard onto different usb
host controllers, so I can disable wakeup for the mouse host
controller and enable wakeup for the keyboard host controller,
then it should be possible to wake the system by pressing a key. :)
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
