linux-kernel - 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]
Message-ID: <20080531221223.GA2630@yamamaya.is-a-geek.org>
Date:	Sun, 1 Jun 2008 00:12:24 +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>,
	David Brownell <david-b@...bell.net>,
	linux-acpi@...r.kernel.org, linux-pm@...ts.linux-foundation.org
Subject: Re: [PATCH 0/4] Fix forcedeth hibernate/wake-on-lan problems

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@...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.
> 
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/