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

[Vytas]

My laptop (Lenovo Thinkpad x230, i5-3320M (Ivy Bridge) based) reboots spontaneously shortly after shutdown.
This happens only if the system has been previously woken up from a suspend.

I am using TLP to optimize battery usage but I tried disabling it and it does not change anything.

This happens with both linux-image-generic (3.13.0.45) and linux-image-generic-lts-utopic (3.16.0.30), but it this is a fairly new problem, introduced with the updates 1-3 weeks ago or so. I haven't found the time to trace the exact last linux-image-generic that worked well, but as said, the system has been working as expected until fairly recently.

Research of the subject on the internet reveals that the underlying cause is spurious wakeups from the USB controller. Will link to a Linux kernel bug.

Adding xhci_hcd.quirks=262144 to the kernel command line seems to fix the problem with no noticeable (so far) side effects.

The expected behaviour is that Ubuntu kernels should function properly without need for manual workaround.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-generic-lts-utopic 3.16.0.30.23
ProcVersionSignature: Ubuntu 3.16.0-30.40~14.04.1-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.6
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Feb 7 22:27:33 2015
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-06-04 (248 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
SourcePackage: linux-meta-lts-utopic
UpgradeStatus: No upgrade log present (probably fresh install)

[ganastasiouGR (ganastasiougr-linux-kernel-bugs)]

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.

[ganastasiouGR (ganastasiougr-linux-kernel-bugs)]

Created attachment 116791
config

[aaron.lu (aaron.lu-linux-kernel-bugs)]

Does v3.11 have this problem?

[ganastasiouGR (ganastasiougr-linux-kernel-bugs)]

(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.

[aaron.lu (aaron.lu-linux-kernel-bugs)]

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

[ganastasiouGR (ganastasiougr-linux-kernel-bugs)]

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.

[ganastasiouGR (ganastasiougr-linux-kernel-bugs)]

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

[tianyu.lan (tianyu.lan-linux-kernel-bugs)]

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

[sarah (sarah-linux-kernel-bugs)]

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?

[tiwai (tiwai-linux-kernel-bugs)]

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.

[ganastasiouGR (ganastasiougr-linux-kernel-bugs)]

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).

[tiwai (tiwai-linux-kernel-bugs)]

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

[tiwai (tiwai-linux-kernel-bugs)]

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

[ganastasiouGR (ganastasiougr-linux-kernel-bugs)]

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.

[tiwai (tiwai-linux-kernel-bugs)]

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.

[ganastasiouGR (ganastasiougr-linux-kernel-bugs)]

Glad i helped.

[tiwai (tiwai-linux-kernel-bugs)]

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) {

[tiwai (tiwai-linux-kernel-bugs)]

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...

[ganastasiouGR (ganastasiougr-linux-kernel-bugs)]

Created attachment 117531
lspci -nv

[tianyu.lan (tianyu.lan-linux-kernel-bugs)]

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

[dashing.meng (dashing.meng-linux-kernel-bugs)]

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.

[niklas (niklas-linux-kernel-bugs)]

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

[tiwai (tiwai-linux-kernel-bugs)]

(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 ;)

[tiwai (tiwai-linux-kernel-bugs)]

(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.

[niklas (niklas-linux-kernel-bugs)]

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.

[tiwai (tiwai-linux-kernel-bugs)]

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?

[niklas (niklas-linux-kernel-bugs)]

- 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

[tiwai (tiwai-linux-kernel-bugs)]

(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.

[niklas (niklas-linux-kernel-bugs)]

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?

[tiwai (tiwai-linux-kernel-bugs)]

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.

[niklas (niklas-linux-kernel-bugs)]

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.

[art1 (art1-linux-kernel-bugs)]

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.

[sarah (sarah-linux-kernel-bugs)]

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.

[sarah (sarah-linux-kernel-bugs)]

<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?

[sarah (sarah-linux-kernel-bugs)]

<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.

[dashing.meng (dashing.meng-linux-kernel-bugs)]

(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.

[dashing.meng (dashing.meng-linux-kernel-bugs)]

(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.

[niklas (niklas-linux-kernel-bugs)]

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.

[maarten (maarten-linux-kernel-bugs)]

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

[corsseir (corsseir-linux-kernel-bugs)]

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.

[saunders.52 (saunders.52-linux-kernel-bugs)]

(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.

[corsseir (corsseir-linux-kernel-bugs)]

(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

[corsseir (corsseir-linux-kernel-bugs)]

(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

[corsseir (corsseir-linux-kernel-bugs)]

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.

[corsseir (corsseir-linux-kernel-bugs)]

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.

[corsseir (corsseir-linux-kernel-bugs)]

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.

[michael.korn (michael.korn-linux-kernel-bugs)]

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.

[Vytas (vytas)]

FWIW, I am not using Wake-on-LAN and disabling it in BIOS makes no difference.

[delobeldavid (delobeldavid-linux-kernel-bugs)]

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.

[jlmaturanag (jlmaturanag-linux-kernel-bugs)]

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

[corsseir (corsseir-linux-kernel-bugs)]

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"

[jlmaturanag (jlmaturanag-linux-kernel-bugs)]

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).

[jlmaturanag (jlmaturanag-linux-kernel-bugs)]

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

[judorange (judorange-linux-kernel-bugs)]

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

[mossroy (mossroy-linux-kernel-bugs)]

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).

[jamundso (jamundso-linux-kernel-bugs)]

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?

[smirky (smirky-linux-kernel-bugs)]

(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.

[corsseir (corsseir-linux-kernel-bugs)]

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

[alan (alan-linux-kernel-bugs)]

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.

[corsseir (corsseir-linux-kernel-bugs)]

(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.

[corsseir (corsseir-linux-kernel-bugs)]

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.

[ronan.salmon (ronan.salmon-linux-kernel-bugs)]

> 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

[yann-externe.soubeyrand (yann-externe.soubeyrand-linux-kernel-bugs)]

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.

[yann-externe.soubeyrand (yann-externe.soubeyrand-linux-kernel-bugs)]

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

[alan (alan-linux-kernel-bugs)]

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.

[yann-externe.soubeyrand (yann-externe.soubeyrand-linux-kernel-bugs)]

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

Florian is the colleague of mine who wrote the patch.

[yann-externe.soubeyrand (yann-externe.soubeyrand-linux-kernel-bugs)]

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)?

[alan (alan-linux-kernel-bugs)]

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

[mathias.nyman (mathias.nyman-linux-kernel-bugs)]

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.

[yann-externe.soubeyrand (yann-externe.soubeyrand-linux-kernel-bugs)]

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).

[francois.cid (francois.cid-linux-kernel-bugs)]

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

[ystianher (ystianher-linux-kernel-bugs)]

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.

[ystianher (ystianher-linux-kernel-bugs)]

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.

[laurent (laurent-linux-kernel-bugs)]

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.

[mrhamid.qp (mrhamid.qp-linux-kernel-bugs)]

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

[chris (chris-linux-kernel-bugs)]

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
  ...

[giannamelo (giannamelo-linux-kernel-bugs)]

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.

[giannamelo (giannamelo-linux-kernel-bugs)]

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!

[gutaper (gutaper-linux-kernel-bugs)]

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?