Re: [PATCH 0/4] Fix forcedeth hibernate/wake-on-lan problems
- From: Tobias Diedrich <ranma+kernel@xxxxxxxxxxxx>
- Date: Sun, 1 Jun 2008 00:12:24 +0200
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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Prev by Date: Re: [Bug #10825] appletouch after wakeup
- Next by Date: Re: [PATCH 0/3] 64-bit futexes: Intro
- Previous by thread: Re: [Bug #10825] appletouch after wakeup
- Next by thread: Re: [linux-pm] [PATCH 0/4] Fix forcedeth hibernate/wake-on-lan problems
- Index(es):
Relevant Pages
|
