System reboots instead of shutdown (if previously unsuspended) (workaround available)

Created attachment 116781
Dmesg output

I have intel core i5-4570 using asrock h87 pro4 motherboard.
The problem is that i cannot shutdown at all, i have to poweroff pressing and holding power off button on case. This problem appeared using 3.12 kernel.

I have attached dmesg.

Created attachment 116791
config

Does v3.11 have this problem?

(In reply to Aaron Lu from comment #2)
> Does v3.11 have this problem?

No thanks for asking, because i forgot to mention this in my first post.

Can you please do a git bisect to find out the offending commit?

I will but i am not so familiar with git. But it would be a good way to learn something. Thanks, i will be back.

The offending commit is the following.

638298dc66ea36623dbc2757a24fc2c4ab41b016 is the first bad commit
commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
Author: Takashi Iwai <email address hidden>
Date: Thu Sep 12 08:11:06 2013 +0200

    xhci: Fix spurious wakeups after S5 on Haswell

    Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show
    mysterious wakeups after shutdown occasionally. After discussing with
    BIOS engineers, they explained that the new BIOS expects that the
    wakeup sources are cleared and set to D3 for all wakeup devices when
    the system is going to sleep or power off, but the current xhci driver
    doesn't do this properly (partly intentionally).

    This patch introduces a new quirk, XHCI_SPURIOUS_WAKEUP, for
    fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci
    shutdown ops as done in xhci_stop(), and setting the device to PCI D3
    at shutdown and remove ops.

    The PCI D3 call is based on the initial fix patch by Oliver Neukum.

    [Note: Sarah changed the quirk name from XHCI_HSW_SPURIOUS_WAKEUP to
    XHCI_SPURIOUS_WAKEUP, since none of the other quirks have system names
    in them. Sarah also fixed a collision with a quirk submitted around the
    same time, by changing the xhci->quirks bit from 17 to 18.]

    This patch should be backported to kernels as old as 3.0, that
    contain the commit 1c12443ab8eba71a658fae4572147e56d1f84f66 "xhci: Add
    Lynx Point to list of Intel switchable hosts."

    Cc: Oliver Neukum <email address hidden>
    Signed-off-by: Takashi Iwai <email address hidden>
    Signed-off-by: Sarah Sharp <email address hidden>
    Cc: <email address hidden>

:040000 040000 6ba54ba0725b8b93e1beff0ed0c8ac0a729f7502 8330c3a748392abc47843a538752d06048ecc0db M drivers

The commit shows the bug is caused by xhci driver and so reassign to USB component.

Giorgos: Can you retest with 3.12, but revert commit 638298dc66ea36623dbc2757a24fc2c4ab41b016? I.e. `git reset --hard v3.12` and then `git revert 638298dc66ea36623dbc2757a24fc2c4ab41b016`.

Takashi: Could this have been caused by not disabling PCI wakeup before putting the xHCI host into D3 in xhci_shutdown?

It's difficult to judge only from this information...

You can try to unload xhci_hcd module first, then halt. This should behave same as normal shutdown, because the driver puts to D3 at its removal, too.

If module unload behaves same, then you can try to forcibly set the device to D0 at the next step.

After unloading xhci_hcd module, adjust the power state via setpci. For example, suppose that XHCI PCI entry is 00:14.0, the following command (run as root)

    setpci -s 00:14.0 CAP_PM+4.b

shows the current value. The bit 0 & 1 correspond to the power state, (0 = D0, 3 = D3). Suppose this value being 0b, it means D3. For changing this to D0, run like:

    setpci -s 00:14.0 CAP_PM+4.b=08

You can see the current state via lspci -s 00:14.0 -s, too.

After changing to D0, try to halt the machine again to see whether the above changes the power off behavior.

Hello again,

Removing the commit 638298dc66ea36623dbc2757a24fc2c4ab41b016, halt is working.

Takashi: I tried to change power state using setpci, setting it to 08. And in this case, halt isn't working(module unloaded).

Did you turn on to D0 on all XHCI ports? Also check the actual power state via lspci before testing the power off.

Another thing: try to shut down with the reverted kernel but after unloading xhci module. Does this work?

About changing power state on all XHCI ports, only 00:14.0 has xhci_hcd module. Give me some info if you mean to each hub port how can i change their states...

About the second suggestion, halt isn't working with the reverted kernel after xhci_hcd is unloaded.

Thanks. This implies that xhci_reset() call (either in xhci_shutdown for the quirk or xhci_stop() in general at remove callback) breaks the power off, not by the power state change.

Glad i helped.

Could you give lspci -nv output?

We can narrow down this quirk to only HP machines as a quick workaround.

--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -128,7 +128,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
                 * any other sleep) on Haswell machines with LPT and LPT-LP
                 * with the new Intel BIOS
                 */
- xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
+ if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP)
+ xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
        }
        if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
                        pdev->device == PCI_DEVICE_ID_ASROCK_P67) {

Of course, the above patch won't fix perfectly. As already tested, if xhci_hcd is module is unloaded, it hangs at shutdown. So, for such machines, we'd need another quirk not to reset at remove. But, this should be a rare case, so we may ignore for now...

Created attachment 117531
lspci -nv

*** Bug 66551 has been marked as a duplicate of this bug. ***

I tested on the bad kernel(Debian experimental kernel: 3.12-trunk-amd64), "modprobe -r xhci_hcd" before shutdown, problem is still there; "setpci -s 00:14.0 CAP_PM+4.b=08" doesn't work; combine "modprobe -r xhci_hcd" and "setpci -s 00:14.0 CAP_PM+4.b=08" doesn't work too.

And, I found both cases in this bug are related to ASRock motherboard, "asrock h87 pro4" of Giorgos aka shad0w and "asrocofficiallyk z87 pro3" of mine. So, is it a motherboard design or motherboard BIOS bug? The BIOS version is newest of my motherboard.

As Takashi Iwai said: "this should be a rare case, so we may ignore for now...", if both Linux kernel and Asrock think this is a rare case(for this asrock motherboard, they support Windows officially, so Linux user is a rare case). Then, the common user will get a unnormal system.

I have this same problem on a Haswell based Schenker S413 runing 3.13-rc2 and it happens on every shutdown. I would suspect there will be quite a few Linux users of machines like mine as it has Iris Pro graphics which works absolutely wonderful on Linux and a very high resolution display.

Anyway I would be willing to try patches, workarounds etc.
Here is my lspci -nv http://pastebin.com/0861VS7J

(In reply to littlebat from comment #20)
> As Takashi Iwai said: "this should be a rare case, so we may ignore for
> now...", if both Linux kernel and Asrock think this is a rare case(for this
> asrock motherboard, they support Windows officially, so Linux user is a rare
> case). Then, the common user will get a unnormal system.

The rare case mentioned there is that the system goes shutdown after xhci_hcd module is unloaded manually. Usually xhci_hcd module stays loaded, or it's not loaded at all.

For fixing the shutdown hang after module unload, we'd need yet another quirk; this is another BIOS bug, after all. What I said is that such a new quirk won't be needed urgently because unloading xhci_hcd doesn't happen often in normal operations.

(And we know that it's not a rare case that people don't read the context carefully before starting rants ;)

(In reply to Niklas Schnelle from comment #21)
> I have this same problem on a Haswell based Schenker S413 runing 3.13-rc2
> and it happens on every shutdown. I would suspect there will be quite a few
> Linux users of machines like mine as it has Iris Pro graphics which works
> absolutely wonderful on Linux and a very high resolution display.
>
> Anyway I would be willing to try patches, workarounds etc.
> Here is my lspci -nv http://pastebin.com/0861VS7J

The workaround is simple, a patch pasted in comment 16. Apply it manually.

Would you check the test procedure in comment 9, too? If the shutdown hangs after unloading xhci_hcd module, this must be the same BIOS bug.

Ok, I tested without the patch (going to try that tomorrow after some coursework is due) and did:
modprobe -r xhci_hcd
setpci -s 00:14.0 CAP_PM+4.b=08

on poweroff after this, I get no change in behavior. The machine turns completely off and restarts after about 2 seconds.

Well, your description is unclear. Please clarify the following:

- Is your initial problem the hangup at shutdown with the recent 3.12.y or 3.13-rc kernel while 3.12.0 worked (i.e. regression)?

- Does the machine hang up at shutdown after unloading xhci_hcd module, too?

- Does the machine still hang up at shutdown after unloading xhci_hcd module and turning the device to D0 forcibly via setpci?

- Is 00:14.0 is the correct, and it's only XHCI controller on your machine?

- Is the value 08 deduced from the original value read from setpci?

- My original problem manifested itself as described in this bug https://bugzilla.kernel.org/show_bug.cgi?id=66551
that was merged into this one. I haven't done the git bisect though but can confirm that it works with a live system with 3.11

- I tried
#modprobe -r xhci_hcd
#setpci -s 00:14.0 CAP_PM+4.b=08
#systemctl poweroff

with this my behaviour is still the same poweroff then reboot as in the 66551 bug

- 00:14.0 is the only thing in lspci -nv mentioning xhci
- "setpci -s 00:14.0 CAP_PM+4.b" shows "08" so yes

(In reply to Niklas Schnelle from comment #26)
> - My original problem manifested itself as described in this bug
> https://bugzilla.kernel.org/show_bug.cgi?id=66551
> that was merged into this one.

It shouldn't be merged unless it's really spotted to be the exact same bug...
In anyway, I was confused by some description here and there. Now it's cleared. Thanks.

> I haven't done the git bisect though but can
> confirm that it works with a live system with 3.11

Then better to check whether the patch fixes the issue. It's much faster than bisecting.

> - I tried
> #modprobe -r xhci_hcd
> #setpci -s 00:14.0 CAP_PM+4.b=08

Is it with the patched kernel? Otherwise something is wrong. Which kernel are you testing...?

The previous commit for Haswell S5 fix was to make this to 0b (= D3). 08 means it's still D0, i.e. the quirk wasn't applied.

I haven't checked with any patches yet because I'm a bit time limited until tomorrow. I'm running 3.13-rc2 on Arch Linux. Poweroff works with an Ubuntu 13.10 live system that uses 3.11. User littlebat did a bisect on the other bug and found the same commit as the bisect for this bug.

I'm also a little confused now, doing
#modprobe -r xhci_hcd
#setpci -s 00:14.0 CAP_PM+4.b=08
#systemctl poweroff

should make the system hang on poweroff on unpatched kernels or only on patched ones?

Unloading xhci_hcd on a Haswell machine with the recent kernel should reset the link and set the controller to D3. Thus CAP_PM+4 should show the least two bits 03.

If you shutdown after unloading the module, it's essentially identical with the normal shutdown with the quirk -- i.e. it'll reboot soon. However, you can change to D0 via setpci before doing the shutdown. If the problem persists even with the manual D0 adjustment, it would mean that the root cause is the xhci_reset() call. OTOH, if changing to D0 influences on the shutdown behavior, it means that the D3 power-state is the root cause.

So to minimize confusion here is a detailed commandline log of what I did. This is with unpatched 3.13-rc2.
http://pastebin.com/Eqw1xx79
after the shutdown command it shutoff normally and then restarted after a few seconds.

Hi, I have the same problem. Shutting down works correctly on 3.11.10 kernel and results in a restart after a few seconds on 3.12. Hardware: ASRock B85 Pro4 motherboard (latest BIOS), Haswell i5 4670. I put more info here: http://marc.info/?l=linux-acpi&m=138521027528049&w=2

I tried 3.12.4 with a patch from comment 16 applied but it didn't change anything. Also, after removing xhci_hcd module my mouse and keyboard lose power and my system hangs.

It seems there's some confusion, so let me clarify:

The patch in #16 should fix the following case: shutdown with the xhci_hcd module loaded.

It will not fix the case where xhci_hcd is unloaded before the system is shutdown. However, we expect that most users won't unload the xHCI driver before shutting down their system, so this shouldn't be an issue.

Reporters, please try the patch mentioned in #16 against a vanilla 3.12 stable kernel, and shutdown with the xhci_hcd module *loaded* to see if it helps. Please update this sighting with whether the patch helped or not.

So far:

Giorgos reports reverting commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 "xhci: Fix spurious wakeups after S5 on Haswell" allows the system to shutdown without rebooting when the xhci_hcd module is loaded. He hasn't tried Takashi's to see if it helps, please do so.

<email address hidden>: It's unclear what you mean by, "I tried 3.12.4 with a patch from comment 16 applied but it didn't change anything. Also, after removing xhci_hcd module my mouse and keyboard lose power and my system hangs."

The patch didn't help with which test? Shutting down with the xHCI driver loaded, or shutting down with it unloaded?

<email address hidden>: Also, please use git bisect between 3.11 and 3.12 to figure out where the regression occurred, so that we can know whether your regression is due to that commit, or another commit.

(In reply to Sarah Sharp from comment #32)

> Reporters, please try the patch mentioned in #16 against a vanilla 3.12
> stable kernel, and shutdown with the xhci_hcd module *loaded* to see if it
> helps. Please update this sighting with whether the patch helped or not.

I am reporter of bug #66551: https://bugzilla.kernel.org/show_bug.cgi?id=66551 which has been marked as Duplicate of this bug #66171.

I tried kernel 3.12.4 with a patch from comment 16 applied, and shutdown with the xhci_hcd module *loaded*, poweroff works normally now.

If use kernel 3.12.4 don't applied patch in comment 16, poweroff with xhci_hcd module *loaded*, the machine reboot.

(In reply to Takashi Iwai from comment #22)
> (In reply to littlebat from comment #20)
> > As Takashi Iwai said: "this should be a rare case, so we may ignore for
> > now...", if both Linux kernel and Asrock think this is a rare case(for this
> > asrock motherboard, they support Windows officially, so Linux user is a
> rare
> > case). Then, the common user will get a unnormal system.
>
> The rare case mentioned there is that the system goes shutdown after
> xhci_hcd module is unloaded manually. Usually xhci_hcd module stays loaded,
> or it's not loaded at all.
>
> For fixing the shutdown hang after module unload, we'd need yet another
> quirk; this is another BIOS bug, after all. What I said is that such a new
> quirk won't be needed urgently because unloading xhci_hcd doesn't happen
> often in normal operations.
>
> (And we know that it's not a rare case that people don't read the context
> carefully before starting rants ;)

Sorry, I misunderstood your meaning. I don't distinguish very clearly between shutdown with xhci_hcd loaded and unloaded.

Thanks for all of your work. No current Linux if no your effort.

Sorry to say this but I'm getting some weird behavior here. So I built with the patch from comment #16 and tried powering of from within KDE, this lead to the
undesired reboot behavior.
Then just to retry I tried again from GDM and it successfully powerd off.
So I retried with "sudo systemctl poweroff" from within KDE and got a reboot again.
Then I tried twice from a KDM console with "sudo systemctl poweroff" and GDM running, both times powering off worked. So I rebooted into my unpatched kernel and to my surprise that reboots both from GDM, KDE and console.

So the patch only seems to fix it if I don't start a KDE session. Just wanted to let you all know before I retest that whole thing with Gnome, logging out of KDE and so on.

Ok so retried over a dozen times all with the patched kernel, I got maybe half or less correct poweroff and the rest was reboots, also I couldn't find a pattern. Sorry I don't know this is just weird.

Ok, so I did another more methodical test. 10 poweroff tries with each kernel
all straigt to GDM and then poweroff via the menu. Sadly things don't get much clearer:

Unpatched Kernel: 10 tries, 10 reboots, 0 poweroff
Patched Kernel: 10 tries, 5 reboots, 5 poweroff

(In reply to Niklas Schnelle from comment #39)
> Ok, so I did another more methodical test. 10 poweroff tries with each kernel
> all straigt to GDM and then poweroff via the menu. Sadly things don't get
> much clearer:
>
> Unpatched Kernel: 10 tries, 10 reboots, 0 poweroff
> Patched Kernel: 10 tries, 5 reboots, 5 poweroff

Which kernel were you patching? 3.13-rc2 or 3.12.2?

It's odd that it would reboot half the time. The patch from comment #16 should have been the same as reverting the original commit, at least for your system.

Hmm. Perhaps there's another patch that's causing the reboots? If you're testing with 3.13, can you try an unpatched 3.12.3? Try to shutdown as soon as you log into GDM. Then try 3.12.3 with the patch from comment #16.

Notes on Niklas' bug report:
 - 3.11 works
 - 3.13-rc2 fails
 - hasn't done a git bisect to identify the problematic commit

I patched Linus' master from like two hours ago, while the other 3.13 was an 3.13-rc2 I haven't compiled myself. Sadly I haven't really time to do a git bisect until maybe next week Friday. Those 2 test runs with 10 tries each were with Poweroff from the GDM menu so no logging in and I also tried not to vary time to Poweroff much.

So here is what I'm going to try next:
1. 10 Tries with 3.12.3 with that same GDM -> Poweroff scheme
2. Build my own 3.11 and confirm that it really works with the same scheme as above

Sorry to say this but now I'm totally confused:

3.12.3 from Arch Core: 10 tries, 10 reboots, 0 poweroff

3.11 Vanilla locally compiled: 15 tries, 5 reboots, 9 poweroff, 1 kernel panic on poweroff: sorry for the bad quality
http://niklas.sceneproject.org/panic-shutdown.jpg

3.10.23-lts from Arch Core: 3 tries, 2 reboots, 1 poweroff

would have done more tests but have to get up again in 6 1/2 hours...

(In reply to Niklas Schnelle from comment #42)
> Sorry to say this but now I'm totally confused:
>
> 3.12.3 from Arch Core: 10 tries, 10 reboots, 0 poweroff
>
> 3.11 Vanilla locally compiled: 15 tries, 5 reboots, 9 poweroff, 1 kernel
> panic on poweroff: sorry for the bad quality
> http://niklas.sceneproject.org/panic-shutdown.jpg
>
> 3.10.23-lts from Arch Core: 3 tries, 2 reboots, 1 poweroff
>
> would have done more tests but have to get up again in 6 1/2 hours...

Thank you for testing! Unfortunately, it looks like your reboot issues aren't related to the xHCI issue that Giorgos and littlebat reported, since that code was added in 3.12. Please file a separate bug, so that we can close this one. I would also suggest you see if there's a BIOS update for your system and try that before filing the bug. Sorry I couldn't be more helpful.

My previous claim that the patch (from comment 16) doesn't work is invalid (I incorrectly applied it).

I applied it on top of 3.13-rc3 and it fixes the problem. I did 8 shutdowns (using a command "sudo poweroff") and it worked correctly 8 times.

Thanks for quickly fixing it.

Ok, I will open a new bug report as soon as I've got a little more time on my hands. I still think it's related with this issue though, because without the quirk i.e. with older kernels or witch the patch from comment 16 I get somewhat 50% correct shutdowns while with the HP quirk, that is newer kernels without the patch I consistently get 100% reboots.

Is runtime PM enabled? If yes, what if disabling it via sysfs?

How do I disable this? /sys/firmware/acpi/pm_profile isn't writable.
Also I checked there are no firmware updates available.

(In reply to Niklas Schnelle from comment #45)
> Ok, I will open a new bug report as soon as I've got a little more time on
> my hands. I still think it's related with this issue though, because without
> the quirk i.e. with older kernels or witch the patch from comment 16 I get
> somewhat 50% correct shutdowns while with the HP quirk, that is newer
> kernels without the patch I consistently get 100% reboots.

I suppose except for this bug #66171, you have some kernel unrelated issue too.

Suggest try to find this issue:

1, Test kernel 3.11 or before, don't start the GUI desktop(like gnome, kde, xfce, etc.), this can be done by forbid GUI login service(e.g., sudo chmod -x /etc/init.d/gdm3). Then poweroff machine under text console with command: sudo shutdown -h now;

2, Test with other distro LiveCD with kernel 3.11 or before;

3, Install a fresh Linux only with command line, no X;

4, Remove all power managment components, such as: acpid, pm-utils, cpufreq-utils, etc..

Why exactly do you think there are non kernel related issues? My system works great except for the power off issue. Also note that these are not normal reboots,
it shuts completely off and only after about 3 seconds it turns itself back on.
I think the fast that /sys/firmware/acpi/pm_profile is not writeable is also supposed to be like that, I was merely pointing out that I don't know which /sys file is used to turn off PM. Also I can't really see the point with your suggestions for finding the issue. As I said it is clearly related to this issue though possibly more kernel commits are involved but bisecting is very hard because I'd have to test every bisect about 10 times because it tends to work quite a couple of times in a row. The thing is I really can't say if it ever worked because I don't have this laptop for long enough and there really is little reason to power off a laptop, I tend to reboot for updates and suspend when I don't use it so, at least this issue is only mildly annoying but I'd still like to see it fixed as it is I need to do "systemctl halt" and then press the power button if I want to shut down properly and safely.

I have the same problem with Kernel 3.12.6 (openSUSE Tunbleweed). All power management components are off (acpid, ...). Even if I boot only to single user mode, after poweroff command the system restarts again. Kernel 3.11 (Knoppix or openSUSE 13.1) works fine.

Stephan: Does applying the patch in #19 to 3.12.6 help?

Please post the output of `sudo lspci -vvv`, `sudo lspci -vvv -n`, and `sudo dmidecode`. Who is your motherboard manufacturer?

Sorry it's coming this late, I seem to have had problems with mails bouncing and getting lost.

Dmidecode: http://pastebin.com/4wcE9B74
lspci -vvv: http://pastebin.com/P5K4ie23
lspci -vvv -n: http://pastebin.com/NUYtAn8S

hope this helps

Sarah, here are the requested informations:

# uname -a
Linux test 3.12.6-5.g080d0df-desktop #1 SMP PREEMPT Tue Dec 24 10:38:59 UTC 2013 (080d0df) x86_64 x86_64 x86_64 GNU/Linux

# dmidecode
http://pastebin.com/RKQZ5w4c

# lspci -vvv
http://pastebin.com/j6caQ8UT

# lspci -vvv -n
http://pastebin.com/8vEU5dt8

Currently I'm not on the bleeding edge patch level.

Sarah:

> Who is your motherboard manufacturer?

Here are the hardware details:
http://www.asrock.com/nettop/Intel/VisionX%20Series%20%28Haswell%29/#Specifications

I have a Schenker S413 just like Niklas and run Arch Linux. I also experience the problem under the "normal" 3.12 kernels from the arch repositories and with the power cord plugged in (not while on battery though...). However, with the current 3.13 mainline kernel, the problem does not seem to occur. I have read that 3.13 doesn't use xhci power saving features, which would correspond to that being the problem...

@Tobias, sounds interesting I'm also running Arch. I think I never tried powering off on battery, I will check that. Could you try powering off several times on 3.13, because for me the issue was intermittent with some newer kernels and I definitely had the problem with 3.13-rc5-mainline (miffe's repository).

Yeah, you're right. I powered off and booted again for several times and about half the time it rebooted after some seconds, even with 3.13 (which I built from linux-mainline in the AUR). But I also tried powering off while on battery some times and it always seemed to stay off.

Does enabling XHCI_SPURIOUS_REBOOT quirk help?

--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -124,6 +124,7 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
  if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
      (pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI ||
       pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI)) {
+ xhci->quirks |= XHCI_SPURIOUS_REBOOT;
   /* Workaround for occasional spurious wakeups from S5 (or
    * any other sleep) on Haswell machines with LPT and LPT-LP
    * with the new Intel BIOS

ok I can confirm that poweroff works when on battery.

(In reply to Giorgos aka shad0w from comment #6)
> Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show
> mysterious wakeups after shutdown occasionally. After discussing with
> BIOS engineers, they explained that the new BIOS expects that the
> wakeup sources are cleared and set to D3 for all wakeup devices when
> the system is going to sleep or power off, but the current xhci driver
> doesn't do this properly (partly intentionally).

I had a similar spurious wakeup problem on my Asus P8Z77-V Premium motherboard (which is a Panther Point chipset). The problem has existed for several kernel and BIOS versions now (currently using the latest available BIOS, version 2104). I'm running Debian stable, with a vanilla kernel.org kernel version 3.12.7. I'm using UEFI-based boot (rEFInd as the boot menu, and ELILO as the Linux loader), dual-booting with Windows 7.

On Windows 7, the system always powers off without problems; on Linux, it consistently wakes up again a few seconds after powering off.

The discussion in this bug contained the clues I needed to test and apply a workaround which seems to be completely effective for my problem so far.

I added these commands to the system halt scripts:
  modprobe -r xhci-hcd
  setpci -s 00:14.0 CAP_PM+4.b=0b

i.e. the shell-level approximation of the XHCI_SPURIOUS_WAKEUP quirk.

Just unloading the xhci-hcd module had no effect to the problem, and I confirmed that the power state was 08 (i.e. D0) after unloading the module manually.

After adding these commands, my system has powered down successfully on Linux 8 times out of 8 so far.

I guess this means my system might benefit from the XHCI_SPURIOUS_WAKEUP quirk too.

Since the need for this quirk seems to be dependent on BIOS issues, this might be applicable on other systems too. My motherboard uses an UEFI-capable BIOS firmware from American Megatrends Inc. (AMI), and after downloading the manual for Giorgos's Asrock H87 pro4 motherboard, I see his MB has the same BIOS manufacturer. Niklas's and Stephan's dmidecode outputs indicate an UEFI-capable AMI BIOS too.

My first guess would be that systems with AMI UEFI BIOS might need XHCI_SPURIOUS_WAKEUP, but obviously more information would be good.

@Takashi Iwai:
That doesn't fix it for me. It always turns back on.

@Matti Kurkela:
That doesn't fix it either for me. With no USB devices connected, the module isn't even loaded, usually.
The notebook, that Niklas and I have definitely has an AMI BIOS. I use it in UEFI boot mode, however. Don't know if that changes anything, though.

Just FWIW, I have been seeing problem with ACPI shutdown on gentoo x64 guest which is running in VirtualBox (4.3.6) on Windows 7 x64 host. Here by ACPI shutdown I mean simply choosing "ACPI shutdown" command from dropdown menu of VB virtual machine console window.

Once I moved from kernel 3.11 to 3.12 ACPI shutdown stopped working. Now I test kernel-3.13.1 and it still does not work.

'shutdown -h now' from the terminal works though.

Created attachment 124821
XHCI_SPURIOUS_WAKEUP for Panther Point devices from Lenovo

Hello,

I was also hit by this bug. My device is a Lenovo Thinkpad S531 with Ivy Bridge respectively Panther Point components. The manufacturer of my UEFI/Bios (latest version 1.11) is Lenovo.

dmidecode: http://pastebin.com/0Wm2zsCG
lspci -vvv: http://pastebin.com/avvCDghE
lspci -vvv -n: http://pastebin.com/cu41BxuV

Attached is a patch that fixes this bug for me. It is narrowed down to devices from Lenovo. The patch applies cleanly to vanilla kernel 3.13.1 and is tested. It would be great if a similar fix could be applied to the mainline kernel and stable kernels.

I have never used anything else than Fedora 20 (initially kernel 3.11.10) on my machine and was never able to power off by doing a normal shutdown. The temporal fix from comment 60 works for me, too. There are several devices from Lenovo which are very similar to mine. Maybe all of them are affected.

Some hint if this patch doesn’t work for you: Perhaps you have to rebuild your initramfs. Xhci-hcd.ko was inside my initramfs and after just recompiling the modules in drivers/usb/host I had to rebuild my initramfs.

(Re-)building an initramfs with dracut:
dracut "" `make kernelrelease`

If there is anything else I can do to help fixing this bug, please ask.

Like you can see here https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1236420 Dell OptiPlex 9020 is affected by the original issue, too. Sine the last kernel update I can no longer showdown our OptiPlex Machines.

The following patch against the newest xhci-pci.c version works on Ubuntu 12.04 with 3.8.0-37-generic on a Dell OptiPlex 9020:

--- xhci-pci.c
+++ linux-lts-raring-3.8.0/drivers/usb/host/xhci-pci.c
@@ -128,7 +128,8 @@
    * yet another BIOS bug on some other machines
    * https://bugzilla.kernel.org/show_bug.cgi?id=66171
    */
- if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP)
+ if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP ||
+ pdev->subsystem_vendor == PCI_VENDOR_ID_DELL)
    xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
  }
  if (pdev->vendor == PCI_VENDOR_ID_ETRON &&

I still suffer under this issue with Ubuntu 14.04.

Having same issues on System76 Galago UltraPro (same hardware as Clevo W740SU and Schenker S413), running Arch Linux x64 (kernel 3.14.3 from official repo). After reading comments here and playing with xhci quirks, I found a combination, which works: XHCI_SPURIOUS_WAKEUP and XHCI_SPURIOUS_REBOOT (both at the same time, individually they are not fixing the issue). Not to rebuild the kernel, I just passed required quirks as module options:

cat /etc/modprobe.d/xhci.conf
options xhci-hcd quirks=270336

where 270336 = (1 << 18) + (1 << 13). After rebuilding ramdisk and rebooting shutdown works fine.

Hopefully this will be helpful for somebody.

Thx, not rebuilding the kernel would be satisfying.
But Ubuntu don't use xhci-hcd as an module. It's compiled into the kernel.
Is there a way to set parameters in this case?

You can pass "xhci_hcd.quirks=xxx" boot option for the built-in xhci-hcd driver.

But, it's still helpful to report any needed quirks option, so that the upstream can fix in the kernel itself.

The boot option seems to have no effect. I tried XHCI_SPURIOUS_WAKEUP+XHCI_SPURIOUS_REBOOT, just XHCI_SPURIOUS_WAKEUP and just XHCI_SPURIOUS_REBOOT.

Running Ubuntu 14.04 I rechecked the patch from
https://bugzilla.kernel.org/show_bug.cgi?id=66171#c65. It still works.

Maybe the option is just missing in your kernel. It's something new.

I have just realized a upstream kernel is working fine (no boot parameters are necessary).
I use http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-rc5-utopic/

I suppose this is the relevant change: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/drivers/usb/host/xhci-pci.c?id=fefb82756e9fd89d0c0d5983e056df81d51eb075

What is the backporting strategy in this case? According to this commit message this patch should be backported: https://github.com/torvalds/linux/commit/c09ec25d3684cad74d851c0f028a495999591279

When should the patch be backported to kernel 3.13 (used by Ubuntu 14.04)?

The upstream change listed by Michael Korn covers Renesas xHCI controllers on any chipset and HP controllers on Lynxpoint chipsets.

Kernel 3.13 is marked EOL at kernel.org as of 2014-04-22, so Ubuntu will probably have to deal with the backport at the distribution level. In this case, the backport would be pretty trivial.

@Tobias Theobald: the problem seems to be that the BIOS powers up the xHCI controller before the OS is booted up, but won't power it down properly if the OS does not do that at shutdown. If you don't load the xhci-hcd module at all, the system will definitely suffer from this issue as the code to apply the quirk is within the module.

I'm attaching a modified version of Marcus Husar's patch, to cover both my Asus and his Lenovo systems with Ivy Bridge+PPT.

Created attachment 136201
XHCI_SPURIOUS_WAKEUP for Panther Point devices from Asus & Lenovo

@Matti Kurkela: I need this quirk for a Dell OptiPlex 9020, too!

You are right, 3.13 is EOL. I didn't check this, because Ubuntu 14.04 LTS was just a week earlier released.

(In reply to Michael Korn from comment #76)
@Matti Kurkela: sorry, please forget my last comment.

@Michael Korn: No problem.

To summarize: there seems to be (at least) two groups of vendor/chipset combos here with a similar issue with xHCI controllers at power off time.

Asus and Lenovo have had it with Ivy Bridge/Panther Point chipsets. I attached a modified version of Marcus's patch to cover these.

The other group includes HP and Dell with the Lynxpoint chipsets. This is handled by a different set of conditions a few lines down from the Ivy Bridge case, so it might be worthwhile to have a separate patch for that.

I noticed that on my system at least, the reboot-after-powerdown behavior appears also when the system is shut down through a bootloader command (both rEFInd and GRUB). I would assume that the bootloaders mostly rely on firmware in USB matters, so it really looks like a BIOS issue. Just for fun, I'm seeing if I can replicate the workaround with an UEFI shell script (idea: unbind/unload the USB drivers, then manipulate PCI power state, then shutdown) but no success yet...

...if this can help:
I have a desktop with Ububtu 14.04 -64 bit, cpu i5-4670K CPU @ 3.40GHz, motherboard ASRock Z87M Pro4.
With kernel 3.13.0-32-generic I have the same issue: after poweroff the pc turns completely off and restarts after 2-3 seconds.
With kernel 3.13.0-30- generic, on the contrary, the behaviour is correct: the machine just turns off.
If you need more details ask me.

ASRock Z87M Pro4 has a Lynxpoint chipset.

After a quick peek to Ubuntu's http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_3.13.0-32.57.diff.gz, it looks like they have backported the same quirk for Lynxpoint chipsets Michael Korn mentioned: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/drivers/usb/host/xhci-pci.c?id=fefb82756e9fd89d0c0d5983e056df81d51eb075

I could not find a similar file for Ubuntu kernel package 3.13.0-30, but the Ubuntu kernel package changelog says that this change was backported for kernel package version 3.13.0-31.55. So I guess Michael Korn's system probably powers off correctly now?

Mario, it looks like the change that probably made Michael's system work correctly has caused yours to fail. Since 3.13.0 does not seem to have the ability to take the xhci quirks value as a kernel/module option (the suggestion by Takashi Iwai), and as Michael said Ubuntu has xhci-hcd compiled-in to the kernel, you would have to compile a custom kernel to test.

In your case, you know that XHCI_SPURIOUS_REBOOT alone does not work for you, so removing that single line would fix it for you. But if you can, see if it works in combination with XHCI_SPURIOUS_WAKEUP, as Aliaksandr Stelmachonak found in comment 67 above.

Attaching your "lspci -nn" and "dmidecode" outputs might be useful too.
Asrock webpages say that in BIOS version 2.10 for your motherboard, an option called "USB Compatibility Patch" was added in the UEFI BIOS. There is no further description, so it might be useful to check if changing that setting has any effect to the poweroff situation. If your BIOS is not up to date, updating it might also help.

Longer term, it might be useful to urge Ubuntu to backport the change from 3.14 that allows to specify xhci quirks as kernel options.

If anyone is interested, my UEFI shell tests didn't work: if I enter the appropriate PCI manipulation command manually, I get locked out of the keyboard and cannot shutdown. If I try to run the commands as a UEFI shell script, the script interpreter reports an error in the PCI manipulation command. A UEFI shell bug, I guess.

maybe you want to have a look to
https://bugzilla.kernel.org/show_bug.cgi?id=76291

Marios and my system will work correctly with Kernel 3.16, I guess

and here the commit:
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/usb/host/xhci-pci.c?id=0a939993bff117d3657108ca13b011fc0378aedb

Created attachment 144661
"mario_lspci-nn"

Created attachment 144671
mario_dmidecode

Asrock Z87 Extreme6 - Latest uefi 2.30
Intel Haswell i5 4440s
Arch Linux 3.15.7-1

I have the same problem.

Disabling the USB 3.0 controller, I can shutdown.

Hope it will be fixed in 3.16.

Created attachment 144931
asrock z87 extreme 6 lspci log

Sorry, I was absent.
My system (Ubuntu 14.04) works perfect, now. The fix was backported to 3.13.0-32. The problem still exists in 3.13.0-30.

Hopefully ubuntu will also backport the fix for this "fix" :-)

Maybe ubuntu-users should open a new issue in ubuntu bugtracker

(In reply to gdl from comment #85)
> Arch Linux 3.15.7-1

gdl, as your kernel is newer than 3.14, you should be able to apply an easy workaround with module options.

Try these lines in /etc/modprobe.d/xhci.conf (create the file if it does not exist), one at a time:

options xhci-hcd quirks=270336

options xhci-hcd quirks=8192

options xhci-hcd quirks=262144

The first setting enables both XHCI_SPURIOUS_WAKEUP and XHCI_SPURIOUS_REBOOT quirks, the second only XHCI_SPURIOUS_REBOOT and the third only XHCI_SPURIOUS_WAKEUP.

After editing /etc/modprobe.d/xhci.conf, you'll need to run "depmod" and/or recreate your initrd/initramfs, reboot, then see if power-off works.

If your kernel configuration includes the xhci-hcd as built-in instead of as a module, these boot options should be equivalent (again, try just one at a time):

xhci_hcd.quirks=270336

xhci_hcd.quirks=8192

xhci_hcd.quirks=262144

If one or more of these works, please report which quirks setting(s) worked and which did not.

I can't try it now because I don't own that pc.

However, as a workaround, I disabled the usb 3.0 controller from UEFI and it shutdown properly.

https://bugzilla.kernel.org/show_bug.cgi?id=76291 is fixed with Kernel 3.16, Arch published today

This bug is still present for me with Linux 3.16.1-1-ARCH #1 SMP PREEMPT.

I have a Lenovo Yoga 2 11, here is some output from lspci: http://pastebin.com/viwH3HZT.

Let me know what information i can provide to help.

Well this morning coming back from a 4 days holiday, as a miracle, the shutdown of my Ubuntu 14.04 returned to work properly without any change made by me.
I do not know what patches Canonical has made. My kernel remains:
mariora@mariora-desktop:~$ uname -r
3.13.0-35-generic
Tell ma what I can do for understanding what was updated in the system for solving the issue

@mario: you have a new kernel; therefore I guess, ubuntu backported now both patches. You may ask ubuntu

Sorry, what I wrote in the comment 93 was not true. Yes the system did not reboot but I have discovered the really reason. I have had inserted in a USB-2 port a bluetooth dongle an precisely this one "Bus 007 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)". Removing the dongle the system reboots again.
I cannot understand the reason, but I am sure that you can. So no strange Canonical patches but strange (for me) usb ports behaviours.
do you need more informations?

you wrote in https://bugzilla.kernel.org/show_bug.cgi?id=66171#c79 "With kernel 3.13.0-32-generic I have the same issue"; now you have 3.13.0-35-generic.

please ask ubuntu if patch in https://bugzilla.kernel.org/show_bug.cgi?id=66171#c82 is also backported.

sorry, I'm also just a user, and I don't have ubuntu.

I have the same problem on my new laptop.

Lenovo Flex 2 14".
On Arch Linux 3.16.1-1ARCH x86_64

See my reddit post: http://www.reddit.com/r/archlinux/comments/2fjs78/new_laptop_new_arch_install_cant_poweroff/

My problem was solved when upgraded from kernel 3.16.1 to 3.16.2. See comment #97.

I'm seeing the return of this (mis)behavior -- restart rather than shutdown -- on OpenSUSE13.1, with

 uname -a
  Linux desk0107 3.17.1-2.g5c4d099-desktop #1 SMP PREEMPT Sat Oct 18 23:36:23 UTC 2014 (5c4d099) x86_64 x86_64 x86_64 GNU/Linux

and with no USB3 involved,

 lsmod | egrep -i "hci"
  firewire_ohci 44598 0
  firewire_core 72767 1 firewire_ohci
  ohci_pci 13570 0

fyi (ref: http://bugzilla.opensuse.org/show_bug.cgi?id=903560#c1)

booting from OpenSUSE 13.1's LiveKDE cd, with

  kernel 3.11.6-4-desktop

exec of `shutdown -h now` works correctly, powering off the machine completely without subsequent restart.

Hallo,

Nürnberg is calling, Clevo w740su here, xhci_hcd.quirks=270336 fixing the problem. No idea about the other ones, this one however works for me (sofar).

Without the quirk, even on FreeBSD, the system does resume 1-2 seconds after S5, but ONLY when plugged on AC power. On battery power, the problem never occured.

I have an Asrock H97M Pro motherboard which was experiencing these issues ittermentantly, using xhci_hcd.quirks=270336 seems to be fixing it for now, but it's only been two days and it would sometimes go 3 or 4 without showing up. Will respond again if it does reoccur.

I have a similar problem on my Gigabyte GA-990FXA-UD5 motherboard. Running kernel 3.14.26. Setting the xhci_hcd.quirks=270336 doesn't work.

lspci -vvn of xhci: http://pastebin.com/vhXdAkC9

Ignore my previous post, I don't have an Intel system.

Hello, first of all I would like to say thank you for your effort.

I have H87 PRO 4 motherboard and same issue with reboot after shutdown. What kind of information do you need? I am Python developer and I need my machine to work. With this bug my computer is almost unusable. I can provide you all information and data you want, just fix this please.

My rig is:
1. Motheboard: ASRock H87 PRO 4
2. CPU: Intel Core i5 4570 3,2 GHz
3. GPU: ASUS Geforce GTX 750Ti 2GB
4. RAM: Corsair Vengeance 8 GB RAM 1600 MHz
5. Harddrive: Western Digital 500 GB Green

Kernel's versions that I tested without manually applied your patch:

Ubuntu 14.04 - 3.13.0-42 and 3.16.0-28 (branded by Canonical non-vanilla kernels).

Fedora 21 - latest 3.17 (branded by Fedora developers non-vanilla kernel).

I have tried manually setpci. I can not remove xhci_hcd from kernel, after make
#sudo modprobe -r xhci_hcd beacause I get this info: "Can not remove module. Module is built-in".

Nothing works. Intel USB controller is my only xhci device. Please help me fastest as you can.

(In reply to Peter Maciejko from comment #105)
> Hello, first of all I would like to say thank you for your effort.
>
> I have H87 PRO 4 motherboard and same issue with reboot after shutdown. What
> kind of information do you need? I am Python developer and I need my machine
> to work. With this bug my computer is almost unusable. I can provide you all
> information and data you want, just fix this please.
> I have tried manually setpci. I can not remove xhci_hcd from kernel, after
> make
> #sudo modprobe -r xhci_hcd beacause I get this info: "Can not remove module.
> Module is built-in".
>
> Nothing works. Intel USB controller is my only xhci device. Please help me
> fastest as you can.

Since you have a kernel with built in xhci (unlike the Arch example given above) you need to set it on the kernel command line. In /etc/default/grub, there should be a line like:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Add to the end of it before the quotes the extra argument of (try the other quirk numbers mentioned above if this one doesn't work): xhci_hcd.quirks=270336

I think you then run "sudo update-grub" on Ubuntu to regenerate the grub config with this change. Not sure, it's been a while since I last used Ubuntu and most of my machines boot with gummiboot.

(In reply to saunders.52 from comment #106)
> (In reply to Peter Maciejko from comment #105)
> > Hello, first of all I would like to say thank you for your effort.
> >
> > I have H87 PRO 4 motherboard and same issue with reboot after shutdown.
> What
> > kind of information do you need? I am Python developer and I need my
> machine
> > to work. With this bug my computer is almost unusable. I can provide you
> all
> > information and data you want, just fix this please.
> > I have tried manually setpci. I can not remove xhci_hcd from kernel, after
> > make
> > #sudo modprobe -r xhci_hcd beacause I get this info: "Can not remove
> module.
> > Module is built-in".
> >
> > Nothing works. Intel USB controller is my only xhci device. Please help me
> > fastest as you can.
>
> Since you have a kernel with built in xhci (unlike the Arch example given
> above) you need to set it on the kernel command line. In /etc/default/grub,
> there should be a line like:
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
>
> Add to the end of it before the quotes the extra argument of (try the other
> quirk numbers mentioned above if this one doesn't work):
> xhci_hcd.quirks=270336
>
> I think you then run "sudo update-grub" on Ubuntu to regenerate the grub
> config with this change. Not sure, it's been a while since I last used
> Ubuntu and most of my machines boot with gummiboot.

I have followed with you advice and this is result. For hardware which I use

(
  1. Motheboard: ASRock H87 PRO 4
  2. CPU: Intel Core i5 4570 3,2 GHz
  3. GPU: ASUS Geforce GTX 750Ti 2GB
  4. RAM: Corsair Vengeance 8 GB RAM 1600 MHz
  5. Harddrive: Western Digital 500 GB Green
) on Ubuntu 14.04.1 with kernel 3.13.0-43-generic all quirks do not work. But on same Ubuntu version with kernel 3.16.0-28-generic (which also is in the repository) quirk number 262144 works very well. Other quirks (270336 and 8192) do not work.

Conclusion: for my machine enabled XHCI_SPURIOUS_WAKEUP only solve the problem. Again - thanks for you effort and I wish you quickly fix this issue for all machines.

PM

(In reply to Michael Korn from comment #70)
> The boot option seems to have no effect. I tried
> XHCI_SPURIOUS_WAKEUP+XHCI_SPURIOUS_REBOOT, just XHCI_SPURIOUS_WAKEUP and
> just XHCI_SPURIOUS_REBOOT.
>
> Running Ubuntu 14.04 I rechecked the patch from
> https://bugzilla.kernel.org/show_bug.cgi?id=66171#c65. It still works.

Try to install kernel 3.16.0-28-generiv from repo and use xhci_hcd.quirks=262144

I hope this could help you:
http://paste.ubuntu.com/9719183/ lspci -nv
http://paste.ubuntu.com/9719193/ lspci

If you need something else I will help you with pleasure.

Does not work again...

Works in specific case: First I have to reboot my machine and then shutdown - it works and computer goes shutdown corectly. Otherwise it reboot after few seconds. I am talking about quirk 262144. Others does not work even in this specific case.

Hi again!

I have made some reasearch and it seems to work now. Every user that have ASRock motherboard and expirience this issue I would like to go to UEFI settings and then Advanced->ACPI Configuration. Please enable two options:
1. USB Keyboard/Remote Power On
2. USB Mouse Power On
Save changes and reboot by pressing F10.

Before you do this, make sure that you have installed the newest NVIDIA driver from NVIDIA website. I did not test driver from Ubuntu repo or xedgers ppa (including nouveau). I am making fresh install of Ubuntu now to make sure that my solution works fine.

Additional info:

My solution works well with kernel 3.13.0-54-generic and 3.16.0-28 as well.

I had three problems:
1. My machine reboots few seconds after shutdown.
2. Computer goes power off when I pressing power button but he wake up every time when I attach any device to any USB 3.0 port. He stay power off when I make same test with all USB 2.0 ports.
3. My Dell KM714 wireless mouse and keyboard do not work until Ubuntu starting initialisation. I could not enter to UEFI settings or choose others entry in Grub menu.

Solution which I have described upper solve all this issues.

To kernel developers: If you need any additional info I can assure them.

I have made few more test:
My solution fix this bug on Ubuntu 14.10 and Fedora 20/21(the newest 3.17 kernel version) as well.

Sorry for my bad english but I hope you will understand me. Somehow I had to share with my fix of this issue.

Hello again,
this problem with Ubuntu 14.04 was solved already 2 times for me. With the latest Kernel from the repo (3.13.0-44-generic) I have again the reboot problem.
My solution is 3.16.0-29-generic and xhci_hcd.quirks=262144 at the moment. But there is a nvidia-diver problem with this kernel.

Hi,

This happened again (see comments #97, #98).

"rmmod xhci_hcd" before shutdown didn't worked,
xhci_hcd module depends on xhci_pci.

==> Fixed by disabling xHCI Mode in BIOS.

Problem still present, using an Asrock Z87E-ITX, my system is unable to shut down, instead it reboots.

Linux arch-itx 3.18.6-1-ARCH #1 SMP PREEMPT Sat Feb 7 08:44:05 CET 2015 x86_64

Hey @matrs,

Did you try this?

"UEFI settings and then Advanced->ACPI Configuration. Please enable two options:
1. USB Keyboard/Remote Power On
2. USB Mouse Power On"

Hey peter, sorry i didn't read your previous comment, I did now.

If i enable those two options the pc turns off properly. I haven't "usb Keyboard/mouse power on" enabled because in my setup people sometimes press my mouse or keyboard (cleaning stuff) and can turn on my computer by accident. In my case it isn't necessary to enable both options,I left enabled only the "USB Keyboard/Remote Power On" but not the usb mouse option.

Somehow related, for the KDE users, at first, turning off using the kde menu button didn't work, It hung my computer at the shutdown screen (which didn't happen before changing those option in the UEFI). When I checked the "System Settings-->Startup and Shutdown-->Session Management" the "Default leave option" was set to "turn off computer" but changing it to "End current session" solve the problem and now i can shut down my computer using the kde GUI(using poweroff or systemctl poweroff works properly just the GUI option hung my computer).

I still have a related problem, not in every shutdown but it is still recurrent.Despite have done the "ACPI Configuration" change in the UEFI.
My system doesn't shutdown at all, it hangs and i have to turn it off pressing the power button.
Here is a relevant part from from my last failed shutdown log, I added the 'debug' option to the kernel line in grub.

http://pastebin.com/hKCZxANn

This is directly related to the use of a new usb keyboard, using an os/2 keyboard fixes this shutdown problem so im pretty sure it is the same problem discussed here.

Linux arch-itx 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux

Hi,
I had this problem and using the xhci_hcd.quirks=262144 as boot option fixed it.
Disabling xhci in the UEFI also works but it's not really a fix. I have not tried the other quirks.

Linux version 3.19.3-3-ARCH (builduser@tobias) (gcc version 4.9.2 20150304 (prerelease) (GCC) ) #1 SMP PREEMPT Wed Apr 8 14:10:00 CEST 2015

I faced this issue on a Lenovo Flex 2-14, with Ubuntu 14.04.3 (kernel 3.19.0-28-generic #30~14.04.1-Ubuntu SMP Tue Sep 1 09:32:55 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux , provided by Ubuntu)

Same experience as above : adding xhci_hcd.quirks=262144 kernel parameter fixed the issue (Disabling xHCI in the UEFI is also a workaround).

HP zBook 15. Fedora and Ubuntu.

Changing BIOS settings helped (I'm not sure which one :( ), but we should not consider that a "fix" anyway.

I cannot see the NEEDINFO request anywhere above, where is it?
Also, is there another bug for 4.x kernels?

(In reply to Jerry Amundson from comment #120)
> HP zBook 15. Fedora and Ubuntu.
>
> Changing BIOS settings helped (I'm not sure which one :( ), but we should
> not consider that a "fix" anyway.
>
> I cannot see the NEEDINFO request anywhere above, where is it?
> Also, is there another bug for 4.x kernels?

I have the exact same laptop and the exact same problem, using Archlinux with kernel 4.4.1
Pushing the power button restart, "systemctl poweroff" and "poweroff" reboot too.
I checked multiple times the files in /etc/systemd/* but nothing suspicious...
99.99% sure it's a kernel bug.

This bug has three years, what kind of info do you need?

The USB one that this was about was fixed some time ago. If people are still seeing it on some machines with 4.4 then I'd post a report to linux-usb about it.

(In reply to Alan from comment #123)
> The USB one that this was about was fixed some time ago. If people are
> still seeing it on some machines with 4.4 then I'd post a report to
> linux-usb about it.

The bug still persists. I have ASRock H87 PRO 4 and when the usb 3.0 controller is enabled, my computer reboots after poweroff all the time. Of course when I disable usb 3.0 controller then eveything works fine.

When usb 3.0 controller is enabled, I have to first make reboot and after that works fine but only once.

lspci: http://pastebin.com/ZnBitdUH
lsusb: http://pastebin.com/SWWJH8Dx
lsusb -t: http://pastebin.com/des76CdE

My mouse and keyboard are connected with computer through usb ports in monitor Dell U2414H.

Ahh I forgot about one more useful info. Even if computer is turned off properly when I click left button/right button/scroll with my mouse then computer starts to run. All power on * options in UEFI Setup are disabled. If usb 3.0 controller is disabled, then computer doesnt start to run, but leds on my keyboard and mouse light up.

> xhci_hcd.quirks=270336
>
> xhci_hcd.quirks=8192
>
> xhci_hcd.quirks=262144
>
> If one or more of these works, please report which quirks setting(s) worked
> and which did not.

I try ubuntu 14.x and 15.x. kernels up to 4.4.x, and nothing would make my computer turn off.

Thanks to you, adding "xhci-hcd.quirks=262144" (other don't work) to the kernel boot options did the trick.

Here is my working conf :

Ubuntu 14.04.1 LTS vmlinuz-3.19.8-031908-generic x86_64 xhci-hcd.quirks=262144

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05) (prog-if 30 [XHCI])
 Subsystem: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI
 Flags: bus master, medium devsel, latency 0, IRQ 26
 Memory at f7120000 (64-bit, non-prefetchable) [size=64K]
 Capabilities: [70] Power Management version 2
 Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
 Kernel driver in use: xhci_hcd
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05) (prog-if 20 [EHCI])
 Subsystem: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2
 Flags: bus master, medium devsel, latency 0, IRQ 16
 Memory at f7137000 (32-bit, non-prefetchable) [size=1K]
 Capabilities: [50] Power Management version 2
 Capabilities: [58] Debug port: BAR=1 offset=00a0
 Capabilities: [98] PCI Advanced Features
 Kernel driver in use: ehci-pci
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05) (prog-if 20 [EHCI])
 Subsystem: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1
 Flags: bus master, medium devsel, latency 0, IRQ 23
 Memory at f7136000 (32-bit, non-prefetchable) [size=1K]
 Capabilities: [50] Power Management version 2
 Capabilities: [58] Debug port: BAR=1 offset=00a0
 Capabilities: [98] PCI Advanced Features
 Kernel driver in use: ehci-pci

Created attachment 230161
Patch fixing spurious wakeup and spurious reboot problems (at least for our HP machines but should work for other vendors).

The patch I added fixes the spurious wakeup and spurious reboot problems for our HP machines (notably HP Zbook 15) but it should work for other vendors too. It would be great if people could confirm that in order that kernel developers could consider including this patch.

Aren't this bug and https://bugzilla.kernel.org/show_bug.cgi?id=76291 duplicates?

Maybe - would be interesting to know if the patch fixes that one too.

The patch looks fine but we aren't able to accept patches without a proper signed-off-by as per Documentation/SubmittingPatches.

Created attachment 230181
Add Signed-off-by: line to the previous patch

Florian is the colleague of mine who wrote the patch.

Just for my information, is a Signed-off-by: line with a team name valid or is a physical person name required (I suspect the latter but am still wondering myself)?

I guess in theory be a corporation if it qualifies as a legal entity, but it would normally be a person.

The XHCI_SPURIOUS_WAKEUP flag was originally set for both Lynxpoint and Lynxpoint LP back in 2013.
It has since then been set on and off for some time now for due to different regressions. I'll re-check with the hw team about the and add it again if necessary.

The history of this flag is best described in the latest patch that touched it:

commit fd7cd061adcf5f7503515ba52b6a724642a839c8
Author: Laura Abbott <email address hidden>
Date: Mon Oct 12 11:30:13 2015 +0300

    xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

    We received several reports of systems rebooting and powering on
    after an attempted shutdown. Testing showed that setting
    XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT
    quirk allowed the system to shutdown as expected for LynxPoint-LP
    xHCI controllers. Set the quirk back.

    Note that the quirk was originally introduced for LynxPoint and
    LynxPoint-LP just for this same reason. See:

    commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell")

    It was later limited to only concern HP machines as it caused
    regression on some machines, see both bug and commit:

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
    commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines")

    Later it was discovered that the powering on after shutdown
    was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP
    machine suffered from spontaneous resume from S3 (which should
    not be related to the SPURIOUS_WAKEUP quirk at all). An attempt
    to fix this then removed the SPURIOUS_WAKEUP flag usage completely.

    commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell")

    Current understanding is that LynxPoint-LP (Haswell ULT) machines
    need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and
    plain Lynxpoint (Haswell) machines may _not_ have the quirk
    set otherwise they again will restart.

My understanding is that the XHCI_SPURIOUS_WAKEUP and XHCI_SPURIOUS_REBOOT flags are tightly related: in the history of these two flags which I linked in my commit message, one can see that applying one of these flag seems to fix a bug but introduces a new one which is fixed by applying the other flag.

As I tried to highlight in the commit message, these two flags seem not to have been applied at the same time for machines having non-LP LynxPoint controllers except for HP machines between commit c09ec25d3684cad74d851c0f028a495999591279 ("xhci: Switch Intel Lynx Point ports to EHCI on shutdown.") and commit 0a939993bff117d3657108ca13b011fc0378aedb ("xhci: Switch only Intel Lynx Point-LP ports to EHCI on shutdown.").

From the comments along this bug report, it seems that applying these two flags seems to fix the problems for machines having non-LP LynxPoint controllers, at least for certain vendors, which we confirm for HP machines.

Feel free to ask us if you need help in testing. We will be glad to help you (to the extent that we have the availability to do so).

Same problem:

With USB 3.0 enabled on bios, PC restart after shutdown
With USB 3.0 disabled on bios, PC shutdown without restart

Hardware: Dell Optiplex 9020 with latest bios (A16)
OS: Ubuntu 16.04 & 16.04.1

Same issue here, but it doesnt matter if USB3 is enabled or disabled in BIOS. PC restarts after shutdown if WOL is enabled in BIOS.

Hardware: Dell T20, BIOS A11
OS: UEFI installed debian 8.6 with Kernel 3.16.0-4-amd64 and 4.8.0-0.bpo.2-amd64

But the written solution from above helps:
Add xhci_hcd.quirks=270336 to kernel boot options
After this PC doesnt restart after shutdown.

Same on Ubuntu.

Hardware: Dell T20, BIOS A11
OS: UEFI installed Ubuntu 16.04.1 LTS with Kernel 4.4.0-31-generic

But the written solution from above helps:
Add xhci_hcd.quirks=270336 to kernel boot options
After this PC doesnt restart after shutdown.

Same issue on T1700, we initially looked after a potential issue with e1000e and WOL as disabling WOL fixed the spurious start issue but it looks like xhci is the real issue here.

Hardware: Dell Precision T1700 BIOS A26 in Legacy mode (non UEFI)
OS: Debian 9 with kernel from backports 4.14.0-0.bpo.3-amd64

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04)
00:14.0 0c03: 8086:8c31 (rev 04) (prog-if 30 [XHCI])
 Subsystem: 1028:05a6
 Flags: bus master, medium devsel, latency 0, IRQ 27
 Memory at f7820000 (64-bit, non-prefetchable) [size=64K]
 Capabilities: [70] Power Management version 2
 Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
 Kernel driver in use: xhci_hcd
 Kernel modules: xhci_pci

xhci_hcd.quirks=270336 allows a proper poweroff.

Without this option a few second after poweroff the machine powers on.

Same issue linux mint 20 :(
dual boot(windows10,mint20)

I have a same problem, suspending or hibernating immediately wakes up.
Acer Aspire ES 11
None of the 3 xhci_hcd.quirks works for me.

# uname -a
Linux aspires11 5.4.97-gentoo #1 SMP Sat Feb 13 14:49:03 AST 2021 x86_64 Intel(R) Celeron(R) CPU N3350 @ 1.10GHz GenuineIntel GNU/Linux

# lspci
00:00.0 Host bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Host Bridge (rev 0b)
00:00.1 Signal processing controller: Intel Corporation Device 5a8c (rev 0b)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 500 (rev 0b)
00:0e.0 Audio device: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster (rev 0b)
00:0f.0 Communication controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Trusted Execution Engine (rev 0b)
00:12.0 SATA controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SATA AHCI Controller (rev 0b)
00:13.0 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #1 (rev fb)
00:13.2 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #3 (rev fb)
00:13.3 PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #4 (rev fb)
00:15.0 USB controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series USB xHCI (rev 0b)
00:17.0 Signal processing controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series I2C Controller #5 (rev 0b)
00:1c.0 SD Host controller: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series eMMC Controller (rev 0b)
00:1f.0 ISA bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Low Pin Count Interface (rev 0b)
00:1f.1 SMBus: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series SMBus Controller (rev 0b)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
03:00.0 Network controller: Intel Corporation Dual Band Wireless-AC 3168NGW [Stone Peak] (rev 10)

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 3.00
  bDeviceClass 9 Hub
  bDeviceSubClass 0
  bDeviceProtocol 3
  bMaxPacketSize0 9
  idVendor 0x1d6b Linux Foundation
  idProduct 0x0003 3.0 root hub
  bcdDevice 5.04
  iManufacturer 3 Linux 5.4.97-gentoo xhci-hcd
  iProduct 2 xHCI Host Controller
  iSerial 1 0000:00:15.0
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 0x001f
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xe0
      Self Powered
      Remote Wakeup
    MaxPower 0mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 1
      bInterfaceClass 9 Hub
      bInterfaceSubClass 0
  ...

Hi all,

Just want to comment that I had this issue for a long time on my Acer V5 laptop running Ubuntu (currently on 22.10, but also with all the previous releases).

Today I test the fix, editing the grub configuration and adding:

"GRUB_CMDLINE_LINUX_DEFAULT="[...] xhci_hcd.quirks=8192"

then running
`sudo update-grub`
and it fixed the reboot after the shutdown issue.

I also tested the other quirks with my machine and:

options xhci-hcd quirks=270336 -> OK
options xhci-hcd quirks=8192 -> NOT WORKING
options xhci-hcd quirks=262144 -> OK

Laptop specs:
Acer Aspire V5-571G 15,6
CPU Intel i3-2367M, 4GB
GPU GeForce GT 620M 1GB

Hope it may help, cheers.

Ops, in the command example I copied the only quirks not working on my laptop!
Just ignore it and use the list as a reference for my configuration!

I have Asrock J5040-ITX motherboard. Wiith attached USB cable from Eaton 5S 650i UPS PC won't poweroff (reboot instead)

If I unplug usb cable before shutdown - everything fine.

None of mentioned quirks above not working. I tried unbind usb device before shutdown (write to /sys/bus/usb/drivers/usb/unbind) - no success.

Is any other quirks exist?