netdev - Re: [PATCH 0/4] Fix forcedeth hibernate/wake-on-lan problems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 25 May 2008 20:13:29 +0200
From:	Tobias Diedrich <ranma+kernel@...edrich.de>
To:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	Ayaz Abdulla <aabdulla@...dia.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Stephen Hemminger <shemminger@...ux-foundation.org>
Subject: Re: [PATCH 0/4] Fix forcedeth hibernate/wake-on-lan problems

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@...chior:~$ 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.

Hope that helps,

-- 
Tobias						PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html