Bug 66171 - [PATCH]Poweroff doesn't work, it just reboots
[PATCH]Poweroff doesn't work, it just reboots
Status: NEEDINFO
Product: Drivers
Classification: Unclassified
Component: USB
All Linux
: P1 high
Assigned To: XHCI bugs virtual user
:
: 66551 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-29 19:27 UTC by Giorgos aka shad0w
Modified: 2016-08-31 14:19 UTC (History)
32 users (show)

See Also:
Kernel Version: 3.12.1
Tree: Mainline
Regression: No


Attachments
Dmesg output (63.44 KB, application/octet-stream)
2013-11-29 19:27 UTC, Giorgos aka shad0w
Details
config (73.46 KB, application/octet-stream)
2013-11-29 19:27 UTC, Giorgos aka shad0w
Details
lspci -nv (3.75 KB, application/octet-stream)
2013-12-05 08:35 UTC, Giorgos aka shad0w
Details
XHCI_SPURIOUS_WAKEUP for Panther Point devices from Lenovo (775 bytes, patch)
2014-02-06 16:53 UTC, Marcus Husar
Details | Diff
XHCI_SPURIOUS_WAKEUP for Panther Point devices from Asus & Lenovo (827 bytes, patch)
2014-05-15 13:48 UTC, Matti Kurkela
Details | Diff
"mario_lspci-nn" (2.16 KB, text/plain)
2014-07-30 05:54 UTC, mario rava
Details
mario_dmidecode (9.91 KB, text/plain)
2014-07-30 05:54 UTC, mario rava
Details
asrock z87 extreme 6 lspci log (11.99 KB, text/plain)
2014-08-03 08:52 UTC, gdl
Details
Patch fixing spurious wakeup and spurious reboot problems (at least for our HP machines but should work for other vendors). (2.50 KB, patch)
2016-08-25 09:47 UTC, Yann Soubeyrand
Details | Diff
Add Signed-off-by: line to the previous patch (2.56 KB, patch)
2016-08-25 12:57 UTC, Yann Soubeyrand
Details | Diff

Description Giorgos aka shad0w 2013-11-29 19:27:28 UTC
Created attachment 116781 [details]
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.
Comment 1 Giorgos aka shad0w 2013-11-29 19:27:56 UTC
Created attachment 116791 [details]
config
Comment 2 Aaron Lu 2013-12-02 07:26:45 UTC
Does v3.11 have this problem?
Comment 3 Giorgos aka shad0w 2013-12-02 07:31:16 UTC
(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.
Comment 4 Aaron Lu 2013-12-02 07:37:56 UTC
Can you please do a git bisect to find out the offending commit?
Comment 5 Giorgos aka shad0w 2013-12-02 10:04:15 UTC
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.
Comment 6 Giorgos aka shad0w 2013-12-04 11:32:44 UTC
The offending commit is the following. 

638298dc66ea36623dbc2757a24fc2c4ab41b016 is the first bad commit
commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
Author: Takashi Iwai <tiwai@suse.de>
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 <oneukum@suse.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Cc: stable@vger.kernel.org

:040000 040000 6ba54ba0725b8b93e1beff0ed0c8ac0a729f7502 8330c3a748392abc47843a538752d06048ecc0db M	drivers
Comment 7 Lan Tianyu 2013-12-04 13:07:19 UTC
The commit shows the bug is caused by xhci driver and so reassign to USB component.
Comment 8 Sarah Sharp 2013-12-04 16:29:36 UTC
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?
Comment 9 Takashi Iwai 2013-12-04 16:57:18 UTC
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.
Comment 10 Giorgos aka shad0w 2013-12-04 17:22:10 UTC
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).
Comment 11 Takashi Iwai 2013-12-04 17:25:49 UTC
Did you turn on to D0 on all XHCI ports?  Also check the actual power state via lspci before testing the power off.
Comment 12 Takashi Iwai 2013-12-04 17:29:36 UTC
Another thing: try to shut down with the reverted kernel but after unloading xhci module.  Does this work?
Comment 13 Giorgos aka shad0w 2013-12-04 17:43:52 UTC
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.
Comment 14 Takashi Iwai 2013-12-04 17:46:49 UTC
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.
Comment 15 Giorgos aka shad0w 2013-12-04 17:49:11 UTC
Glad i helped.
Comment 16 Takashi Iwai 2013-12-05 07:02:25 UTC
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) {
Comment 17 Takashi Iwai 2013-12-05 07:04:46 UTC
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...
Comment 18 Giorgos aka shad0w 2013-12-05 08:35:00 UTC
Created attachment 117531 [details]
lspci -nv
Comment 19 Lan Tianyu 2013-12-08 12:30:59 UTC
*** Bug 66551 has been marked as a duplicate of this bug. ***
Comment 20 littlebat 2013-12-09 07:55:00 UTC
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.
Comment 21 Niklas Schnelle 2013-12-09 09:42:27 UTC
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
Comment 22 Takashi Iwai 2013-12-09 10:05:49 UTC
(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  ;)
Comment 23 Takashi Iwai 2013-12-09 10:08:40 UTC
(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.
Comment 24 Niklas Schnelle 2013-12-09 12:04:36 UTC
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.
Comment 25 Takashi Iwai 2013-12-09 13:08:13 UTC
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?
Comment 26 Niklas Schnelle 2013-12-09 13:38:55 UTC
- 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
Comment 27 Takashi Iwai 2013-12-09 13:49:45 UTC
(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.
Comment 28 Niklas Schnelle 2013-12-09 14:00:30 UTC
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?
Comment 29 Takashi Iwai 2013-12-09 14:08:07 UTC
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.
Comment 30 Niklas Schnelle 2013-12-09 19:24:32 UTC
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.
Comment 31 art1 2013-12-09 22:34:42 UTC
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.
Comment 32 Sarah Sharp 2013-12-10 00:49:54 UTC
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.
Comment 33 Sarah Sharp 2013-12-10 00:53:21 UTC
art1@vhex.net: 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?
Comment 34 Sarah Sharp 2013-12-10 00:54:42 UTC
art1@vhex.net: 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.
Comment 35 littlebat 2013-12-10 07:08:15 UTC
(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.
Comment 36 littlebat 2013-12-10 07:14:48 UTC
(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.
Comment 37 Niklas Schnelle 2013-12-10 20:28:38 UTC
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.
Comment 38 Niklas Schnelle 2013-12-10 20:44:05 UTC
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.
Comment 39 Niklas Schnelle 2013-12-10 21:06:12 UTC
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
Comment 40 Sarah Sharp 2013-12-10 21:44:10 UTC
(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
Comment 41 Niklas Schnelle 2013-12-10 22:02:02 UTC
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
Comment 42 Niklas Schnelle 2013-12-10 23:13:33 UTC
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...
Comment 43 Sarah Sharp 2013-12-10 23:26:22 UTC
(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.
Comment 44 art1 2013-12-10 23:47:46 UTC
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.
Comment 45 Niklas Schnelle 2013-12-11 08:40:30 UTC
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.
Comment 46 Takashi Iwai 2013-12-11 08:56:53 UTC
Is runtime PM enabled?  If yes, what if disabling it via sysfs?
Comment 47 Niklas Schnelle 2013-12-11 11:37:40 UTC
How do I disable this? /sys/firmware/acpi/pm_profile isn't writable.
Also I checked there are no firmware updates available.
Comment 48 littlebat 2013-12-12 00:57:04 UTC
(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..
Comment 49 Niklas Schnelle 2013-12-12 09:09:38 UTC
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.
Comment 50 Stephan Böni 2014-01-07 12:28:04 UTC
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.
Comment 51 Sarah Sharp 2014-01-07 22:28:03 UTC
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?
Comment 52 Niklas Schnelle 2014-01-07 23:53:49 UTC
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
Comment 53 Stephan Böni 2014-01-08 08:39:42 UTC
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.
Comment 54 Stephan Böni 2014-01-08 08:44:36 UTC
Sarah:

> Who is your motherboard manufacturer?

Here are the hardware details:
http://www.asrock.com/nettop/Intel/VisionX%20Series%20%28Haswell%29/#Specifications
Comment 55 Tobias Theobald 2014-01-08 18:30:32 UTC
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...
Comment 56 Niklas Schnelle 2014-01-08 19:11:14 UTC
@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).
Comment 57 Tobias Theobald 2014-01-10 07:48:50 UTC
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.
Comment 58 Takashi Iwai 2014-01-10 08:50:18 UTC
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
Comment 59 Niklas Schnelle 2014-01-10 09:31:47 UTC
ok I can confirm that poweroff works when on battery.
Comment 60 Matti Kurkela 2014-01-13 00:45:01 UTC
(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.
Comment 61 Tobias Theobald 2014-01-15 20:29:03 UTC
@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.
Comment 62 Richard Musil 2014-02-01 23:00:57 UTC
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.
Comment 63 Marcus Husar 2014-02-06 16:53:50 UTC
Created attachment 124821 [details]
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.
Comment 64 Michael Korn 2014-03-11 13:10:50 UTC
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.
Comment 65 Michael Korn 2014-03-14 17:15:48 UTC
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 &&
Comment 66 Michael Korn 2014-04-29 16:02:53 UTC
I still suffer under this issue with Ubuntu 14.04.
Comment 67 Alex 2014-05-10 02:39:58 UTC
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.
Comment 68 Michael Korn 2014-05-12 10:24:20 UTC
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?
Comment 69 Takashi Iwai 2014-05-12 11:35:46 UTC
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.
Comment 70 Michael Korn 2014-05-12 14:01:03 UTC
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.
Comment 71 Takashi Iwai 2014-05-12 14:04:37 UTC
Maybe the option is just missing in your kernel.  It's something new.
Comment 72 Michael Korn 2014-05-12 14:56:09 UTC
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
Comment 73 Michael Korn 2014-05-13 09:33:20 UTC
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)?
Comment 74 Matti Kurkela 2014-05-15 13:46:58 UTC
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.
Comment 75 Matti Kurkela 2014-05-15 13:48:51 UTC
Created attachment 136201 [details]
XHCI_SPURIOUS_WAKEUP for Panther Point devices from Asus & Lenovo
Comment 76 Michael Korn 2014-05-15 14:57:07 UTC
@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.
Comment 77 Michael Korn 2014-05-15 15:05:33 UTC
(In reply to Michael Korn from comment #76)
@Matti Kurkela: sorry, please forget my last comment.
Comment 78 Matti Kurkela 2014-05-16 14:40:49 UTC
@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...
Comment 79 mario rava 2014-07-29 06:42:39 UTC
...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.
Comment 80 Matti Kurkela 2014-07-29 10:42:38 UTC
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.
Comment 81 Wulf 2014-07-29 14:27:15 UTC
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
Comment 83 mario rava 2014-07-30 05:54:02 UTC
Created attachment 144661 [details]
"mario_lspci-nn"
Comment 84 mario rava 2014-07-30 05:54:54 UTC
Created attachment 144671 [details]
mario_dmidecode
Comment 85 gdl 2014-08-03 08:51:59 UTC
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.
Comment 86 gdl 2014-08-03 08:52:28 UTC
Created attachment 144931 [details]
asrock z87 extreme 6 lspci log
Comment 87 Michael Korn 2014-08-07 15:45:28 UTC
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.
Comment 88 Wulf 2014-08-07 17:16:23 UTC
Hopefully ubuntu will also backport the fix for this "fix" :-)

Maybe ubuntu-users should open a new issue in ubuntu bugtracker
Comment 89 Matti Kurkela 2014-08-08 07:55:56 UTC
(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.
Comment 90 gdl 2014-08-09 13:26:48 UTC
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.
Comment 91 Wulf 2014-08-13 07:24:29 UTC
https://bugzilla.kernel.org/show_bug.cgi?id=76291 is fixed with Kernel 3.16, Arch published today
Comment 92 Matthew Hague 2014-08-30 23:11:07 UTC
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.
Comment 93 mario rava 2014-09-02 14:28:21 UTC
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
Comment 94 Wulf 2014-09-02 14:59:45 UTC
@mario: you have a new kernel; therefore I guess, ubuntu backported now both patches. You may ask ubuntu
Comment 95 mario rava 2014-09-03 09:04:10 UTC
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?
Comment 96 Wulf 2014-09-03 09:16:01 UTC
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.
Comment 97 David Delobel 2014-09-06 15:11:10 UTC
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/
Comment 98 David Delobel 2014-09-11 15:55:03 UTC
My problem was solved when upgraded from kernel 3.16.1 to 3.16.2. See comment #97.
Comment 99 GrantK 2014-10-29 19:37:05 UTC
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
Comment 100 GrantK 2014-11-03 03:19:36 UTC
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.
Comment 101 Lars Schotte 2014-12-01 16:59:55 UTC
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.
Comment 102 saunders.52 2014-12-11 06:06:30 UTC
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.
Comment 103 Maarten 2014-12-14 18:28:08 UTC
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
Comment 104 Maarten 2014-12-14 21:22:41 UTC
Ignore my previous post, I don't have an Intel system.
Comment 105 Peter Maciejko 2015-01-10 17:45:24 UTC
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.
Comment 106 saunders.52 2015-01-11 00:26:37 UTC
(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.
Comment 107 Peter Maciejko 2015-01-12 16:06:40 UTC
(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
Comment 108 Peter Maciejko 2015-01-12 16:09:38 UTC
(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
Comment 109 Peter Maciejko 2015-01-12 16:13:29 UTC
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.
Comment 110 Peter Maciejko 2015-01-12 17:45:39 UTC
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.
Comment 111 Peter Maciejko 2015-01-13 15:54:17 UTC
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.
Comment 112 Michael Korn 2015-01-14 14:34:53 UTC
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.
Comment 113 David Delobel 2015-02-12 21:46:08 UTC
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.
Comment 114 matrs 2015-03-11 11:25:32 UTC
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
Comment 115 Peter Maciejko 2015-03-11 13:12:23 UTC
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"
Comment 116 matrs 2015-03-11 15:51:09 UTC
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).
Comment 117 matrs 2015-04-02 05:43:17 UTC
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
Comment 118 Nathan Prat 2015-04-18 09:57:44 UTC
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
Comment 119 Mossroy 2015-09-18 20:24:48 UTC
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).
Comment 120 Jerry Amundson 2016-01-21 13:23:15 UTC
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?
Comment 121 Bogomil Vasilev 2016-02-19 23:06:31 UTC
(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.
Comment 122 Peter Maciejko 2016-03-08 18:59:50 UTC
This bug has three years, what kind of info do you need?
Comment 123 Alan 2016-03-08 20:23:12 UTC
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.
Comment 124 Peter Maciejko 2016-03-08 21:11:00 UTC
(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.
Comment 125 Peter Maciejko 2016-03-08 21:21:43 UTC
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.
Comment 126 Ronan SALMON 2016-06-09 08:04:21 UTC
 
> 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
Comment 127 Yann Soubeyrand 2016-08-25 09:47:53 UTC
Created attachment 230161 [details]
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.
Comment 128 Yann Soubeyrand 2016-08-25 09:48:36 UTC
Aren't this bug and https://bugzilla.kernel.org/show_bug.cgi?id=76291 duplicates?
Comment 129 Alan 2016-08-25 12:31:25 UTC
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.
Comment 130 Yann Soubeyrand 2016-08-25 12:57:09 UTC
Created attachment 230181 [details]
Add Signed-off-by: line to the previous patch

Florian is the colleague of mine who wrote the patch.
Comment 131 Yann Soubeyrand 2016-08-25 12:59:11 UTC
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)?
Comment 132 Alan 2016-08-25 15:57:38 UTC
I guess in theory be a corporation if it qualifies as a legal entity, but it would normally be a person.
Comment 133 Mathias Nyman 2016-08-26 09:28:59 UTC
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 <labbott@fedoraproject.org>
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.
Comment 134 Yann Soubeyrand 2016-08-26 10:23:11 UTC
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).
Comment 135 francois.cid 2016-08-31 14:19:52 UTC
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

Note You need to log in before you can comment on or make changes to this bug.