WOL causes spontaneous power on after shutdown [SOLVED]

R00KIE · 2014-08-23 20:12:13

If someone with a similar board could test (or if you could test) before you spend money, that would be good. It's never a good idea to buy things in the heat of the moment, although I can understand your frustration.

You might be hitting some software or hardware bug, not easy to know since I suspect not many people use wol (and probably it doesn't get much testing from board vendors).

graysky · 2014-08-23 22:08:56

R00KIE wrote:

If someone with a similar board could test (or if you could test) before you spend money, that would be good.

Agreed: https://bbs.archlinux.org/viewtopic.php?id=186093

qwerty12 · 2014-08-23 23:13:53

graysky wrote:

qwerty - Thank you for the post but that is way over my head

Sorry, I'm certainly no expert in the area! So within the BIOS/UEFI, as part of the ACPI subsystem, there's a important table called the DSDT. It does lots of things. For instance, that ASUS laptop I was talking about had non-functional brightness keys. I looked at the kernel's asus-laptop.c driver and saw that it expects specific keycodes from the laptop for it to forward the generic-but-Linux-specific keycode that means brightness. Inside the DSDT function that is called by the laptop when the Fn+Brightness Up key is pressed, I saw it was doing <base keycode for brightness up/down + new brightness level> which isn't understood by asus-laptop. I don't like compiling kernels so I just changed the keycode that was being sent to the one that asus-laptop likes and told GRUB to load the new DSDT table. I could finally control brightness in X with the keyboard (I broke being able to do it from the console but I spend my time in X anyway).

So the gist of it is (expect inaccuracies), when your computer is going from one sleep state to another, the ACPI subsystem will run a function called _PTS (the full details on it can be found in the ACPI specification, linked in my previous post). AppleLife members found that their Hackintoshed PCs would reboot instead of shutting down. They found that having the ACPI subsystem not run the code in the _PTS function solved this. For all I know, that code could be doing important things and while nobody has ever reported anything adverse happening in the four years of the patch's existence, so I consider it unlikely (especially since I've used it myself), it could be preventing the motherboard from, say, making sure that the devices are correctly powered off when shutting down.

Anyway, if my warning hasn't scared you off (I'm glad I'm using a ThinkPad these days where everything just works) and you're willing to give it a try, you can do this:

# cp -a /sys/firmware/acpi/tables tables/
# pacman -S iasl
# cd tables
# mv dynamic/* .
# rmdir dynamic
# ( shopt -s extglob ; rm -f !(DSDT|SSDT*); ) # Assuming bash here
# iasl -da *
# nano DSDT.dsl # I'm not ashamed
Find the "_PTS," function and add "If (LNotEqual(Arg0,5)) {" as the first line of the function and add a "}" as the last line of the function. Save and quit
# iasl DSDT.dsl

Ignore any warning and remark lines and fix the errors that are presented back to you. I'm familiar with some of them. Let me know. Keep running the above until it finally succeeds and you're given a present of a DSDT.aml file in the same folder.

Next step is to actually load the ACPI table. If you're using GRUB with a traditional boot (BIOS boot, legacy, CSM, MBR - whatever) then follow the instructions here to tell GRUB to load the table: https://wiki.archlinux.org/index.php/DS … at_runtime
Ignore the warning, it's GRUB that loads the table, not the kernel.

If you're using a UEFI bootloader then you'll have to build another, separate kernel to load the DSDT.aml. I have no experience with that but the ArchWiki goes over it. Values in the DSDT (like the SystemConfiguration ones) can change when you add/remove RAM so bear that in mind.

EDIT: Of course, I can see why buying another motherboard may be tempting when you look at the above and see how long it takes to implement a workaround that may or may not work...

Last edited by qwerty12 (2014-08-23 23:15:05)

graysky · 2014-08-28 10:22:56

graysky wrote:

MSI H97I AC Mini ITX uses an Realtek 8111E LAN which to different... perhaps I will try it for $110...

Purchased the MSI H97I AC and it does not exhibit this problem (3 days of multiple shut downs/startups per day). Everything else with the board works out-of-the-box with the 3.16.1 kernel. Am very pleased with the results so far, just a little miffed that I had to spend $110 to correct a problem that shouldn't be present. Shame on you, Asus.

emeres · 2014-08-28 11:17:38

@graysky now you could try what qwerty12 proposes 'without risk' so to say.

graysky · 2014-08-28 11:24:49

Too much work. I paid to have this problem go away . I just plan to never purchase an asus board again.

Last edited by graysky (2014-08-28 11:25:11)

yuyu · 2014-10-30 01:24:44

I know it's a couple of months old, but I just tried qwerty12's suggestion and I'm sorry to say it didn't work for me. I had really hoped to say something different.
Nevertheless, it only took an hour or so (I'm experienced with modifying dsdt's, running one right now on this computer) so I don't really think it's too much work. Heck, I'd work for $110/hr anytime, it's almost what I'm worth.
Thank you just the same qwerty12, it might have worked, it was worth the effort. Nothing ventured, nothing gained. I'll keep trying.
It's on an old laptop M/B (HP dv9200), video dead, but core 2 duo still ticking, I'm using it for a distributed C compiler slave. It's going to live in a deep, dark corner so I really need WOL/shutdown working, WOL was easy.

graysky · 2014-11-23 21:14:14

Well, here's a crappy update, the new board has started doing the same behavior as has one of my older P8Z77 boards. WTF?

Most of the time, if the board is powered up by WOL (magic packet) it WILL NOT SHUTDOWN AND STAY DOWN. Rather, it just goes down, waits 3-5 sec then turns right back on. If I unplug the power cord, and do not power on by WOL, but use the power switch, it behaves as it should: `sudo shutdown -h now` shuts the box down and it stays down. I don't think it's hardware specific now since all of my more recent boards are doing it. Anyone else?

guggi · 2015-01-18 18:33:48

Running arch linux on an asus z87i-pro. If i use wol magic packet to bring the system up an than poweroff with shutdoewn -h the drives spin down but after 2-5 seconds system boots up again . Just tried to unplug the power cord and after using the powerswitch to boot the system a simple poweroff is enough to bring the system down, it wont reboot anymore.
if i suspend to disk witch echo disk > /sys/power/state i cant resume by magic packet anymore, system remains powered off even after sending a magig packet.

Last edited by guggi (2015-01-18 18:34:55)

fseek · 2015-04-22 09:58:58

graysky wrote:

Well, here's a crappy update, the new board has started doing the same behavior as has one of my older P8Z77 boards. WTF?
Most of the time, if the board is powered up by WOL (magic packet) it WILL NOT SHUTDOWN AND STAY DOWN. Rather, it just goes down, waits 3-5 sec then turns right back on. If I unplug the power cord, and do not power on by WOL, but use the power switch, it behaves as it should: `sudo shutdown -h now` shuts the box down and it stays down. I don't think it's hardware specific now since all of my more recent boards are doing it. Anyone else?

Same here, I have an ASUS P8B-WS mainboard. Most of the times, the second shutdown works.

I don't think it's ACPI related either, the fix suggested by qwerty12 doesn't actually work: I recompiled the ACPI tables and the problem was still there.

I think this issue started early in the 2.6 kernels but at the time I couldn't track down the causing commit since it's basically impossible to bisect.

graysky · 2015-05-03 14:53:06

An update... recently, I have been testing several systems (Z77 and H97-based) after I disabled all references to 'xHCI' as it pertains to USB settings[1]. I also enabled wake on keyboard[2]. And finally, I disabled EuP 2013 which affects wattage in power off mode. In about 15 power cycles, I haven't observed an unintentional wake-up with 'wake on PCIe' enabled in the BIOS. More time is needed before I will claim either setting is the fix.

1a. https://communities.intel.com/message/168708
1b. https://github.com/torvalds/linux/commi … d644fa7a42
2. http://serverfault.com/questions/349898 … nt-reboots

Last edited by graysky (2015-06-28 10:29:10)

Vi0L0 · 2015-05-08 18:58:43

Thank you graysky for nice finding, it helped me much!
Recently I started playing with WOL and was touched by the problem. I'm using msi z77-gd65 with this bios/efi options: on 'Intel giga interface' options WOL set to enabled, and in 'Wake up events' section I only enabled onboard LAN - all other options, including wake on usb or PCI-E stayed disabled.
WOL works great on Windows side, and it was rebooting on Linux untill I completelly removed xHCI from the kernel config. WOL is working now, but im missing USB 3.0 (furtunatelly im using it very occasionally). Now wondering how to fix it definitelly to keep both USB 3.0 and WOL working... :> I believe it's not switching properly to eHCI on shutdown, dont have time right now to investigate but I should make some tests in lets say next week.

Last edited by Vi0L0 (2015-05-08 19:08:17)

fseek · 2015-05-12 08:18:29

graysky wrote:

An update... recently, I have been testing several systems (Z77 and H97-based) after I disabled all references to 'xHCI' as it pertains to USB settings[1].

hi, thank you for your update.

My mainboard has only one USB3 controller, from ASMEDIA, and that's the only user of the xhci module. After looking at the patches in your link [1] it seems this controller doesn't need the quirk to work.

However, for the sake of convenience, I tried to patch xhci-pci.c and add the quirk also for my controller:

        if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
                        pdev->device == 0x1042) {
                xhci->quirks |= XHCI_BROKEN_STREAMS;
                xhci->quirks |= XHCI_SPURIOUS_REBOOT;
        }

Compiled, rebooted, shutdown, woke on lan and shutdown again. Result: spontaneous power on.
(btw I can reproduce the problem 100% of the times if I power up the machine with a WOL packet)

Conclusion: it doesn't seem to be xhci related.

graysky wrote:

I also enabled wake on keyboard[2]. In about 15 power cycles, I haven't observed an unintentional wake-up with 'wake on PCIe' enabled in the BIOS. More time is needed before I will claim either setting is the fix.
1a. https://communities.intel.com/message/168708
1b. https://github.com/torvalds/linux/commi … d644fa7a42
2. http://serverfault.com/questions/349898 … nt-reboots

I will try the "wake on keyboard" workaround this evening, let's hope for the better

fseek · 2015-05-12 15:23:22

fseek wrote:

I will try the "wake on keyboard" workaround this evening, let's hope for the better

no luck, unfortunately. The system still wakes up by itself just after powering it off.

For the records, to rule out any errors on my side when patching the sources I also blacklisted xhci-pci without success.

For future reference here follows the lspci -v of my machine, maybe the problematic mainboards share a common hardware component:

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 Processor Family DRAM Controller (rev 09)
	Subsystem: ASUSTeK Computer Inc. Device 844d
	Flags: bus master, fast devsel, latency 0
	Capabilities: <access denied>

00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 25
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000e000-0000efff
	Memory behind bridge: f4000000-f60fffff
	Prefetchable memory behind bridge: 00000000e8000000-00000000f3ffffff
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:06.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 26
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Flags: bus master, fast devsel, latency 0, IRQ 11
	Memory at f650b000 (64-bit, non-prefetchable) [size=16]
	Capabilities: <access denied>

00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05) (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Flags: bus master, medium devsel, latency 0, IRQ 16
	Memory at f6508000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>
	Kernel driver in use: ehci-pci
	Kernel modules: ehci_pci

00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
	Subsystem: ASUSTeK Computer Inc. Device 8469
	Flags: bus master, fast devsel, latency 0, IRQ 39
	Memory at f6500000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: 00002000-00002fff
	Memory behind bridge: e0100000-e02fffff
	Prefetchable memory behind bridge: 00000000e0300000-00000000e04fffff
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: f6400000-f64fffff
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b5) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 18
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: f6300000-f63fffff
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1c.7 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 8 (rev b5) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 19
	Bus: primary=00, secondary=06, subordinate=06, sec-latency=0
	Memory behind bridge: f6200000-f62fffff
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05) (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Flags: bus master, medium devsel, latency 0, IRQ 23
	Memory at f6507000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>
	Kernel driver in use: ehci-pci
	Kernel modules: ehci_pci

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5) (prog-if 01 [Subtractive decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=07, subordinate=07, sec-latency=32
	I/O behind bridge: 0000b000-0000bfff
	Memory behind bridge: f6100000-f61fffff
	Capabilities: <access denied>

00:1f.0 ISA bridge: Intel Corporation C206 Chipset Family LPC Controller (rev 05)
	Subsystem: ASUSTeK Computer Inc. P8B WS Motherboard
	Flags: bus master, medium devsel, latency 0
	Capabilities: <access denied>
	Kernel driver in use: lpc_ich

00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05) (prog-if 01 [AHCI 1.0])
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 27
	I/O ports at f070 [size=8]
	I/O ports at f060 [size=4]
	I/O ports at f050 [size=8]
	I/O ports at f040 [size=4]
	I/O ports at f020 [size=32]
	Memory at f6506000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <access denied>
	Kernel driver in use: ahci
	Kernel modules: ahci

00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Flags: medium devsel, IRQ 18
	Memory at f6505000 (64-bit, non-prefetchable) [size=256]
	I/O ports at f000 [size=32]
	Kernel modules: i2c_i801

01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 560] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 2326
	Flags: bus master, fast devsel, latency 0, IRQ 44
	Memory at f4000000 (32-bit, non-prefetchable) [size=32M]
	Memory at e8000000 (64-bit, prefetchable) [size=128M]
	Memory at f0000000 (64-bit, prefetchable) [size=64M]
	I/O ports at e000 [size=128]
	[virtual] Expansion ROM at f6000000 [disabled] [size=512K]
	Capabilities: <access denied>
	Kernel driver in use: nvidia
	Kernel modules: nvidia

01:00.1 Audio device: NVIDIA Corporation GF114 HDMI Audio Controller (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 2326
	Flags: bus master, fast devsel, latency 0, IRQ 40
	Memory at f6080000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
	Subsystem: ASUSTeK Computer Inc. Motherboard
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Memory at f6400000 (32-bit, non-prefetchable) [size=128K]
	I/O ports at d000 [size=32]
	Memory at f6420000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: e1000e
	Kernel modules: e1000e

05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
	Subsystem: ASUSTeK Computer Inc. Motherboard
	Flags: bus master, fast devsel, latency 0, IRQ 18
	Memory at f6300000 (32-bit, non-prefetchable) [size=128K]
	I/O ports at c000 [size=32]
	Memory at f6320000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: e1000e
	Kernel modules: e1000e

06:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller (prog-if 30 [XHCI])
	Subsystem: ASUSTeK Computer Inc. P8B WS Motherboard
	Flags: bus master, fast devsel, latency 0, IRQ 19
	Memory at f6200000 (64-bit, non-prefetchable) [size=32K]
	Capabilities: <access denied>
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

07:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. Device 82eb
	Flags: bus master, medium devsel, latency 32, IRQ 5
	Memory at f6100000 (32-bit, non-prefetchable) [size=2K]
	I/O ports at b000 [size=128]
	Capabilities: <access denied>
	Kernel modules: firewire_ohci

R00KIE · 2015-05-12 18:06:04

I was looking at another thread[1] and I was wondering if you have looked into /proc/acpi/wakeup and tried disabling wake on usb(1), given that you have managed to start to narrow this down to problems with usb.

(1) You have to go into /sys/devices/pci*/$devaddr/power and write to the wakeup file to enable/disable.
[1] https://bbs.archlinux.org/viewtopic.php?id=196846

graysky · 2015-05-12 18:49:21

graysky wrote:

An update... recently, I have been testing several systems (Z77 and H97-based) after I disabled all references to 'xHCI' as it pertains to USB settings[1]. I also enabled wake on keyboard[2]. And finally, I disabled EuP 2013 which affects wattage in power off mode. In about 15 power cycles, I haven't observed an unintentional wake-up with 'wake on PCIe' enabled in the BIOS. More time is needed before I will claim either setting is the fix.
1a. https://communities.intel.com/message/168708
1b. https://github.com/torvalds/linux/commi … d644fa7a42
2. http://serverfault.com/questions/349898 … nt-reboots

It's been 22 days now and I have been pounding on both machines (on then off etc.) and haven't experienced a single unexpected wakeup. I think it's safe to call this a fixed issue with an identified cause that is reproducible enabled and disabled.

Last edited by graysky (2015-06-28 10:29:31)

fseek · 2015-05-14 12:44:23

nice to know, unfortunately those bandaids don't work for me.

fseek · 2015-06-22 23:13:27

An update: I solved the issue, it was a BIOS bug.

I was looking at the disassembly of the DSDT ACPI table to find any bug in the ASL code, double checking with the examples found in the document 074_GPE_Routing.doc that I found in the Web (thanks to an email I got from a user in the linux-acpi mailing list).

I noticed that part of the code was executed only when a certain variable (PMSX) was set. That variable was initialized in one specific ACPI method (NPME) and that method was called only by the _OSC() ACPI method. Then I grepped my dmesg for "_OSC" because I thought I had seen it skimming through the logs and I found this horrible message:

giu 19 18:31:06 zanac kernel: acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
giu 19 18:31:06 zanac kernel: \_SB_.PCI0:_OSC invalid UUID
giu 19 18:31:06 zanac kernel: _OSC request data:1 1f 0
giu 19 18:31:06 zanac kernel: acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM

The _OSC() method called by the ACPI linux code was failing! And as a consequence the NPME() method that initialized some vital variables didn't get called.
Something wrong was happening inside the _OSC() method.

Here follows the disassembled _OSC() code (only the relevant part):

Method (_OSC, 4, Serialized) // _OSC: Operating System Capabilities
{
Store (Arg3, Local0)
CreateDWordField (Local0, Zero, CDW1)
CreateDWordField (Local0, 0x04, CDW2)
CreateDWordField (Local0, 0x08, CDW3)
If (^XHC.CUID (Arg0))
{
Return (^XHC.POSC (Arg1, Arg2, Arg3))
}
Else
{
If (_OSI ("Windows 2012"))
{
If (LEqual (XCNT, Zero))
{
^XHC.XSEL ()
Increment (XCNT)
}
}
}
If (LAnd (LEqual (Arg0, GUID), NEXP))
{
Store (CDW2, SUPP) /* \_SB_.PCI0.SUPP */
Store (CDW3, CTRL) /* \_SB_.PCI0.CTRL */
If (Not (And (CDW1, One)))
{
If (And (CTRL, One))
{
NHPG ()
}
If (And (CTRL, 0x04))
{
NPME ()
}
}
...

In fact the UUID check was passing (I checked and the two UUIDS in the kernel and in the DSDT table were the same) but the NEXP variable was likely to be 0.
From inspecting the disassembly I got the address of NEXP variable (0xDF3ADE18 + 0xE1 + 1) and then I checked its value with this simple program:

#include <stdio.h>
int main()
{
FILE *in = fopen("/dev/mem", "rb");
if (in) {
fseeko(in, 0xDF3ADE18 + 0xE1 + 1, 0);
fprintf(stdout, "%02X\n", getc(in));
fclose(in);
}
return 0;
}

Infact it printed 00 (execute as root with sudo).

So I googled for "_OSC failed NEXP" and I found a bugzilla entry for this issue: https://bugzilla.kernel.org/show_bug.cgi?id=36932
The bugreport concludes that this is a BIOS bug and despite that on Windows it magically works, who knows why...

Now let's talk about the fix: remove any test involving NEXP in the DSDT.dsl file, recompile it and replace the buggy DSDT with the new one.

The instructions to disassemble and reassemble and replace the DSDT table are here https://wiki.archlinux.org/index.php/DSDT

The ASL code above became as follows:

                If (LEqual (Arg0, GUID))
                {
                    Store (CDW2, SUPP) /* \_SB_.PCI0.SUPP */
                    Store (CDW3, CTRL) /* \_SB_.PCI0.CTRL */
                    If (Not (And (CDW1, One)))
                    {
                        If (And (CTRL, One))
                        {
                            NHPG ()
                        }

                        If (And (CTRL, 0x04))
                        {
                            NPME ()
                        }
                    }

I also had to remove another test for the NEXP variable in a different place.

Then I recompiled the DSDT. I had to solve two compilation errors:

1. Return (Zero) was not accepted as a Buffer type => I changed it to Return(ToBuffer(Zero))
2. Name (_HID, "ABCDEFGH") had non HEX digits (!) => I changed it to Name (_HID, "ABCDEFFF") (it referred to a "Docking station" but this is a desktop PC so I think it's a leftover from a generic BIOS that gets then tailored to a specific mainboard).

Then I followed the instructions on the Arch wiki link above to replace the DSDT table by using GRUB.

Result: no spontaneous wakeup anymore! I can't adequately describe how happy I am at the moment :-)

Last edited by fseek (2015-06-22 23:16:18)

graysky · 2015-06-22 23:41:50

@fseek - Nice to know. I agree that it too is a BIOS bug... since disabling the options I mentioned a few posts up, I have experienced a single unplanned wakeup.

ceri · 2015-06-23 05:33:46

@fseek Nice find. I'm guessing you had to compile that into the kernel as the runtime hook no longer works? That seems a PITA.

fseek · 2015-06-23 05:56:33

@graysky: it could be we are seeing two different issues at play here, you can easily check your logs if the _OSC() method is failing.

@ceri: if you want to embed the DSDT table in the kernel you have to recompile it but I suggest to use GRUB to replace the BIOS table: this way the kernel doesn't get tainted and you can go back easily if something goes wrong. EDIT: now I see that warning in the wiki... but it's misplaced: the GRUB method described in that section works perfectly, the bug report talks about loading the DSDT table from initramfs. Somebody should fix the page.

A quick note: the latest version of iasl has some issues when disassembling the ACPI tables, I had to downgrade it to version 20140926-1 to get a proper disassembly.

EDIT: added working version of iasl.

Last edited by fseek (2015-06-23 08:04:13)

fseek · 2015-06-24 12:06:23

Another update: I think I know what's happening but I cannot prove it until this evening when I go back home.

I found a link on the web relevant to the NEXP variable[1] that says:

NEXP, 8, // (226) Native PCIE Setup Value

and I'm beginning to suspect that this "Native PCIE Setup value" is connected some way to the EFI boot.
In other words I think that the BIOS will populate the variable only when booting via EFI.

This would explain why everything works in Windows, since it uses the EFI boot protocol.

This evening/night I'll test this theory and I'll let you know.

If I'm right recompiling the DSDT table won't be needed at all.

[1] https://github.com/tianocore/edk2-Vlv2D … oblNvs.asl

UPDATE: no luck. The only solution that works is the custom DSDT.

Last edited by fseek (2015-06-24 18:27:20)

Vi0L0 · 2015-06-27 11:16:54

Noobish workaround and funny thing - I've found that the thing which is causing the reboot is my screen's usb 3.0 hub (Dell U2713HM). I can now turn WOL on and use usb 3.0 - reboot doesn't happen If I will ie.:
- disconnect hub completelly; (or)
- turn off screen before system's shutdown; (or)
- leave usb 3.0 pendrive (doesn't work with usb 2.0 pendrive) connected to the hub when system is performing shutdown - after shutdown I can safely unplug pendrive.
I performed many shutdowns and WOLs to test it.

superformosa · 2015-12-04 01:23:58

My 2 cents: I experienced this problem with an Asus H87M-E motherboard. These are the settings I changed to fix it:

Advanced -> APM -> Power On By PCIE -> Enabled
Advanced -> USB Configuration -> Intel xHCI Mode -> Disabled
Advanced -> Platform Misc Configuration -> PCI Express Native Power Management -> Enabled
(On selecting the last one, an extra option "Native ASPM" pops up. Leave it disabled)

Hopefully this will help someone with an H87M-E motherboard who finds this thread via Google or the Arch Wiki.

evaristorivi · 2018-04-20 00:29:07

Indeed, I have Gigabyte GAZ77XUD5H
And what happens to me here happens to me. On the same computer, Windows shuts down well but neither El Capitan OS X nor Ubuntu goes off well, it always restarts.

But I do not want to lose usb 3.0
I do not want to disable wake on lan either.

So I configured FixShutdown_0004 bit in Clover
https://clover-wiki.zetam.org/Fixing-DSDT

and everything is fine .. en El Capitan OS X

now it just fails me in Ubuntu ...

Arch Linux

#26 2014-08-23 20:12:13

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#27 2014-08-23 22:08:56

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#28 2014-08-23 23:13:53

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#29 2014-08-28 10:22:56

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#30 2014-08-28 11:17:38

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#31 2014-08-28 11:24:49

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#32 2014-10-30 01:24:44

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#33 2014-11-23 21:14:14

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#34 2015-01-18 18:33:48

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#35 2015-04-22 09:58:58

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#36 2015-05-03 14:53:06

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#37 2015-05-08 18:58:43

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#38 2015-05-12 08:18:29

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#39 2015-05-12 15:23:22

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#40 2015-05-12 18:06:04

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#41 2015-05-12 18:49:21

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#42 2015-05-14 12:44:23

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#43 2015-06-22 23:13:27

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#44 2015-06-22 23:41:50

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#45 2015-06-23 05:33:46

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#46 2015-06-23 05:56:33

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#47 2015-06-24 12:06:23

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#48 2015-06-27 11:16:54

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#49 2015-12-04 01:23:58

Re: WOL causes spontaneous power on after shutdown [SOLVED]

#50 2018-04-20 00:29:07

Re: WOL causes spontaneous power on after shutdown [SOLVED]

Board footer