System reboots instead of shutdown (if previously unsuspended) (workaround available)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Incomplete
|
High
|
|||
linux-meta-lts-utopic (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
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-
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.
The expected behaviour is that Ubuntu kernels should function properly without need for manual workaround.
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-
ProcVersionSign
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-
UpgradeStatus: No upgrade log present (probably fresh install)
In Linux Kernel Bug Tracker #66171, ganastasiouGR (ganastasiougr-linux-kernel-bugs) wrote : | #3 |
In Linux Kernel Bug Tracker #66171, ganastasiouGR (ganastasiougr-linux-kernel-bugs) wrote : | #4 |
Created attachment 116791
config
In Linux Kernel Bug Tracker #66171, aaron.lu (aaron.lu-linux-kernel-bugs) wrote : | #5 |
Does v3.11 have this problem?
In Linux Kernel Bug Tracker #66171, ganastasiouGR (ganastasiougr-linux-kernel-bugs) wrote : | #6 |
(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.
In Linux Kernel Bug Tracker #66171, aaron.lu (aaron.lu-linux-kernel-bugs) wrote : | #7 |
Can you please do a git bisect to find out the offending commit?
In Linux Kernel Bug Tracker #66171, ganastasiouGR (ganastasiougr-linux-kernel-bugs) wrote : | #8 |
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.
In Linux Kernel Bug Tracker #66171, ganastasiouGR (ganastasiougr-linux-kernel-bugs) wrote : | #9 |
The offending commit is the following.
638298dc66ea366
commit 638298dc66ea366
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_
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_
XHCI_
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 1c12443ab8eba71
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 6ba54ba0725b8b9
In Linux Kernel Bug Tracker #66171, tianyu.lan (tianyu.lan-linux-kernel-bugs) wrote : | #10 |
The commit shows the bug is caused by xhci driver and so reassign to USB component.
In Linux Kernel Bug Tracker #66171, sarah (sarah-linux-kernel-bugs) wrote : | #11 |
Giorgos: Can you retest with 3.12, but revert commit 638298dc66ea366
Takashi: Could this have been caused by not disabling PCI wakeup before putting the xHCI host into D3 in xhci_shutdown?
In Linux Kernel Bug Tracker #66171, tiwai (tiwai-linux-kernel-bugs) wrote : | #12 |
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.
In Linux Kernel Bug Tracker #66171, ganastasiouGR (ganastasiougr-linux-kernel-bugs) wrote : | #13 |
Hello again,
Removing the commit 638298dc66ea366
Takashi: I tried to change power state using setpci, setting it to 08. And in this case, halt isn't working(module unloaded).
In Linux Kernel Bug Tracker #66171, tiwai (tiwai-linux-kernel-bugs) wrote : | #14 |
Did you turn on to D0 on all XHCI ports? Also check the actual power state via lspci before testing the power off.
In Linux Kernel Bug Tracker #66171, tiwai (tiwai-linux-kernel-bugs) wrote : | #15 |
Another thing: try to shut down with the reverted kernel but after unloading xhci module. Does this work?
In Linux Kernel Bug Tracker #66171, ganastasiouGR (ganastasiougr-linux-kernel-bugs) wrote : | #16 |
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.
In Linux Kernel Bug Tracker #66171, tiwai (tiwai-linux-kernel-bugs) wrote : | #17 |
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.
In Linux Kernel Bug Tracker #66171, ganastasiouGR (ganastasiougr-linux-kernel-bugs) wrote : | #18 |
Glad i helped.
In Linux Kernel Bug Tracker #66171, tiwai (tiwai-linux-kernel-bugs) wrote : | #19 |
Could you give lspci -nv output?
We can narrow down this quirk to only HP machines as a quick workaround.
--- a/drivers/
+++ b/drivers/
@@ -128,7 +128,8 @@ static void xhci_pci_
* any other sleep) on Haswell machines with LPT and LPT-LP
* with the new Intel BIOS
*/
- xhci->quirks |= XHCI_SPURIOUS_
+ if (pdev->
+ xhci->quirks |= XHCI_SPURIOUS_
}
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
In Linux Kernel Bug Tracker #66171, tiwai (tiwai-linux-kernel-bugs) wrote : | #20 |
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...
In Linux Kernel Bug Tracker #66171, ganastasiouGR (ganastasiougr-linux-kernel-bugs) wrote : | #21 |
Created attachment 117531
lspci -nv
In Linux Kernel Bug Tracker #66171, tianyu.lan (tianyu.lan-linux-kernel-bugs) wrote : | #22 |
*** Bug 66551 has been marked as a duplicate of this bug. ***
In Linux Kernel Bug Tracker #66171, dashing.meng (dashing.meng-linux-kernel-bugs) wrote : | #23 |
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.
In Linux Kernel Bug Tracker #66171, niklas (niklas-linux-kernel-bugs) wrote : | #24 |
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://
In Linux Kernel Bug Tracker #66171, tiwai (tiwai-linux-kernel-bugs) wrote : | #25 |
(In reply to littlebat from comment #20)
> As Takashi Iwai said: "this should be a rare case, so we may ignore for
> now...", if both Linux kernel and Asrock think this is a rare case(for this
> asrock motherboard, they support Windows officially, so Linux user is a rare
> case). Then, the common user will get a unnormal system.
The rare case mentioned there is that the system goes shutdown after xhci_hcd module is unloaded manually. Usually xhci_hcd module stays loaded, or it's not loaded at all.
For fixing the shutdown hang after module unload, we'd need yet another quirk; this is another BIOS bug, after all. What I said is that such a new quirk won't be needed urgently because unloading xhci_hcd doesn't happen often in normal operations.
(And we know that it's not a rare case that people don't read the context carefully before starting rants ;)
In Linux Kernel Bug Tracker #66171, tiwai (tiwai-linux-kernel-bugs) wrote : | #26 |
(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://
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.
In Linux Kernel Bug Tracker #66171, niklas (niklas-linux-kernel-bugs) wrote : | #27 |
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.
In Linux Kernel Bug Tracker #66171, tiwai (tiwai-linux-kernel-bugs) wrote : | #28 |
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?
In Linux Kernel Bug Tracker #66171, niklas (niklas-linux-kernel-bugs) wrote : | #29 |
- My original problem manifested itself as described in this bug https:/
that was merged into this one. I haven't done the git bisect though but can confirm that it works with a live system with 3.11
- I tried
#modprobe -r xhci_hcd
#setpci -s 00:14.0 CAP_PM+4.b=08
#systemctl poweroff
with this my behaviour is still the same poweroff then reboot as in the 66551 bug
- 00:14.0 is the only thing in lspci -nv mentioning xhci
- "setpci -s 00:14.0 CAP_PM+4.b" shows "08" so yes
In Linux Kernel Bug Tracker #66171, tiwai (tiwai-linux-kernel-bugs) wrote : | #30 |
(In reply to Niklas Schnelle from comment #26)
> - My original problem manifested itself as described in this bug
> https:/
> 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.
In Linux Kernel Bug Tracker #66171, niklas (niklas-linux-kernel-bugs) wrote : | #31 |
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?
In Linux Kernel Bug Tracker #66171, tiwai (tiwai-linux-kernel-bugs) wrote : | #32 |
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.
In Linux Kernel Bug Tracker #66171, niklas (niklas-linux-kernel-bugs) wrote : | #33 |
So to minimize confusion here is a detailed commandline log of what I did. This is with unpatched 3.13-rc2.
http://
after the shutdown command it shutoff normally and then restarted after a few seconds.
In Linux Kernel Bug Tracker #66171, art1 (art1-linux-kernel-bugs) wrote : | #34 |
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://
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.
In Linux Kernel Bug Tracker #66171, sarah (sarah-linux-kernel-bugs) wrote : | #35 |
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 638298dc66ea366
In Linux Kernel Bug Tracker #66171, sarah (sarah-linux-kernel-bugs) wrote : | #36 |
<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?
In Linux Kernel Bug Tracker #66171, sarah (sarah-linux-kernel-bugs) wrote : | #37 |
<email address hidden>: Also, please use git bisect between 3.11 and 3.12 to figure out where the regression occurred, so that we can know whether your regression is due to that commit, or another commit.
In Linux Kernel Bug Tracker #66171, dashing.meng (dashing.meng-linux-kernel-bugs) wrote : | #38 |
(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:/
I tried kernel 3.12.4 with a patch from comment 16 applied, and shutdown with the xhci_hcd module *loaded*, poweroff works normally now.
If use kernel 3.12.4 don't applied patch in comment 16, poweroff with xhci_hcd module *loaded*, the machine reboot.
In Linux Kernel Bug Tracker #66171, dashing.meng (dashing.meng-linux-kernel-bugs) wrote : | #39 |
(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.
In Linux Kernel Bug Tracker #66171, niklas (niklas-linux-kernel-bugs) wrote : | #40 |
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.
66 comments hidden Loading more comments | view all 146 comments |
In Linux Kernel Bug Tracker #66171, maarten (maarten-linux-kernel-bugs) wrote : | #107 |
Ignore my previous post, I don't have an Intel system.
In Linux Kernel Bug Tracker #66171, corsseir (corsseir-linux-kernel-bugs) wrote : | #108 |
Hello, first of all I would like to say thank you for your effort.
I have H87 PRO 4 motherboard and same issue with reboot after shutdown. What kind of information do you need? I am Python developer and I need my machine to work. With this bug my computer is almost unusable. I can provide you all information and data you want, just fix this please.
My rig is:
1. Motheboard: ASRock H87 PRO 4
2. CPU: Intel Core i5 4570 3,2 GHz
3. GPU: ASUS Geforce GTX 750Ti 2GB
4. RAM: Corsair Vengeance 8 GB RAM 1600 MHz
5. Harddrive: Western Digital 500 GB Green
Kernel's versions that I tested without manually applied your patch:
Ubuntu 14.04 - 3.13.0-42 and 3.16.0-28 (branded by Canonical non-vanilla kernels).
Fedora 21 - latest 3.17 (branded by Fedora developers non-vanilla kernel).
I have tried manually setpci. I can not remove xhci_hcd from kernel, after make
#sudo modprobe -r xhci_hcd beacause I get this info: "Can not remove module. Module is built-in".
Nothing works. Intel USB controller is my only xhci device. Please help me fastest as you can.
In Linux Kernel Bug Tracker #66171, saunders.52 (saunders.52-linux-kernel-bugs) wrote : | #109 |
(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_
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.
I think you then run "sudo update-grub" on Ubuntu to regenerate the grub config with this change. Not sure, it's been a while since I last used Ubuntu and most of my machines boot with gummiboot.
In Linux Kernel Bug Tracker #66171, corsseir (corsseir-linux-kernel-bugs) wrote : | #110 |
(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_
>
> 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.
>
> 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_
PM
In Linux Kernel Bug Tracker #66171, corsseir (corsseir-linux-kernel-bugs) wrote : | #111 |
(In reply to Michael Korn from comment #70)
> The boot option seems to have no effect. I tried
> XHCI_SPURIOUS_
> just XHCI_SPURIOUS_
>
> Running Ubuntu 14.04 I rechecked the patch from
> https:/
Try to install kernel 3.16.0-28-generiv from repo and use xhci_hcd.
In Linux Kernel Bug Tracker #66171, corsseir (corsseir-linux-kernel-bugs) wrote : | #112 |
I hope this could help you:
http://
http://
If you need something else I will help you with pleasure.
In Linux Kernel Bug Tracker #66171, corsseir (corsseir-linux-kernel-bugs) wrote : | #113 |
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.
In Linux Kernel Bug Tracker #66171, corsseir (corsseir-linux-kernel-bugs) wrote : | #114 |
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.
In Linux Kernel Bug Tracker #66171, michael.korn (michael.korn-linux-kernel-bugs) wrote : | #115 |
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.
113 comments hidden Loading more comments | view all 146 comments |
Vytas (vytas) wrote : | #1 |
- Workaround Edit (463 bytes, text/x-diff)
- Dependencies.txt Edit (3.5 KiB, text/plain; charset="utf-8")
- ProcEnviron.txt Edit (316 bytes, text/plain; charset="utf-8")
Vytas (vytas) wrote : | #2 |
FWIW, I am not using Wake-on-LAN and disabling it in BIOS makes no difference.
113 comments hidden Loading more comments | view all 146 comments |
In Linux Kernel Bug Tracker #66171, delobeldavid (delobeldavid-linux-kernel-bugs) wrote : | #116 |
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.
In Linux Kernel Bug Tracker #66171, jlmaturanag (jlmaturanag-linux-kernel-bugs) wrote : | #117 |
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
In Linux Kernel Bug Tracker #66171, corsseir (corsseir-linux-kernel-bugs) wrote : | #118 |
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"
In Linux Kernel Bug Tracker #66171, jlmaturanag (jlmaturanag-linux-kernel-bugs) wrote : | #119 |
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).
In Linux Kernel Bug Tracker #66171, jlmaturanag (jlmaturanag-linux-kernel-bugs) wrote : | #120 |
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.
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
In Linux Kernel Bug Tracker #66171, judorange (judorange-linux-kernel-bugs) wrote : | #121 |
Hi,
I had this problem and using the xhci_hcd.
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
In Linux Kernel Bug Tracker #66171, mossroy (mossroy-linux-kernel-bugs) wrote : | #122 |
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.
In Linux Kernel Bug Tracker #66171, jamundso (jamundso-linux-kernel-bugs) wrote : | #123 |
HP zBook 15. Fedora and Ubuntu.
Changing BIOS settings helped (I'm not sure which one :( ), but we should not consider that a "fix" anyway.
I cannot see the NEEDINFO request anywhere above, where is it?
Also, is there another bug for 4.x kernels?
In Linux Kernel Bug Tracker #66171, smirky (smirky-linux-kernel-bugs) wrote : | #124 |
(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.
In Linux Kernel Bug Tracker #66171, corsseir (corsseir-linux-kernel-bugs) wrote : | #125 |
This bug has three years, what kind of info do you need?
In Linux Kernel Bug Tracker #66171, alan (alan-linux-kernel-bugs) wrote : | #126 |
The USB one that this was about was fixed some time ago. If people are still seeing it on some machines with 4.4 then I'd post a report to linux-usb about it.
In Linux Kernel Bug Tracker #66171, corsseir (corsseir-linux-kernel-bugs) wrote : | #127 |
(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://
lsusb: http://
lsusb -t: http://
My mouse and keyboard are connected with computer through usb ports in monitor Dell U2414H.
In Linux Kernel Bug Tracker #66171, corsseir (corsseir-linux-kernel-bugs) wrote : | #128 |
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.
In Linux Kernel Bug Tracker #66171, ronan.salmon (ronan.salmon-linux-kernel-bugs) wrote : | #129 |
> xhci_hcd.
>
> xhci_hcd.
>
> xhci_hcd.
>
> 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.
Here is my working conf :
Ubuntu 14.04.1 LTS vmlinuz-
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
In Linux Kernel Bug Tracker #66171, yann-externe.soubeyrand (yann-externe.soubeyrand-linux-kernel-bugs) wrote : | #130 |
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.
In Linux Kernel Bug Tracker #66171, yann-externe.soubeyrand (yann-externe.soubeyrand-linux-kernel-bugs) wrote : | #131 |
Aren't this bug and https:/
In Linux Kernel Bug Tracker #66171, alan (alan-linux-kernel-bugs) wrote : | #132 |
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/
In Linux Kernel Bug Tracker #66171, yann-externe.soubeyrand (yann-externe.soubeyrand-linux-kernel-bugs) wrote : | #133 |
Created attachment 230181
Add Signed-off-by: line to the previous patch
Florian is the colleague of mine who wrote the patch.
In Linux Kernel Bug Tracker #66171, yann-externe.soubeyrand (yann-externe.soubeyrand-linux-kernel-bugs) wrote : | #134 |
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)?
In Linux Kernel Bug Tracker #66171, alan (alan-linux-kernel-bugs) wrote : | #135 |
I guess in theory be a corporation if it qualifies as a legal entity, but it would normally be a person.
In Linux Kernel Bug Tracker #66171, mathias.nyman (mathias.nyman-linux-kernel-bugs) wrote : | #136 |
The XHCI_SPURIOUS_
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 fd7cd061adcf5f7
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_
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:/
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.
In Linux Kernel Bug Tracker #66171, yann-externe.soubeyrand (yann-externe.soubeyrand-linux-kernel-bugs) wrote : | #137 |
My understanding is that the XHCI_SPURIOUS_
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 c09ec25d3684cad
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).
In Linux Kernel Bug Tracker #66171, francois.cid (francois.cid-linux-kernel-bugs) wrote : | #138 |
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
In Linux Kernel Bug Tracker #66171, ystianher (ystianher-linux-kernel-bugs) wrote : | #139 |
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.
After this PC doesnt restart after shutdown.
In Linux Kernel Bug Tracker #66171, ystianher (ystianher-linux-kernel-bugs) wrote : | #140 |
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.
After this PC doesnt restart after shutdown.
In Linux Kernel Bug Tracker #66171, laurent (laurent-linux-kernel-bugs) wrote : | #141 |
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-
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.
Without this option a few second after poweroff the machine powers on.
Changed in linux: | |
importance: | Unknown → High |
status: | Unknown → Incomplete |
In Linux Kernel Bug Tracker #66171, mrhamid.qp (mrhamid.qp-linux-kernel-bugs) wrote : | #142 |
Same issue linux mint 20 :(
dual boot(windows10,
In Linux Kernel Bug Tracker #66171, chris (chris-linux-kernel-bugs) wrote : | #143 |
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
bNumConfigura
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x001f
bNumInterfaces 1
bConfigurat
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescript
bInterfac
bAlternat
bNumEndpoints 1
bInterfac
bInterfac
...
In Linux Kernel Bug Tracker #66171, giannamelo (giannamelo-linux-kernel-bugs) wrote : | #144 |
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_
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.
In Linux Kernel Bug Tracker #66171, giannamelo (giannamelo-linux-kernel-bugs) wrote : | #145 |
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!
In Linux Kernel Bug Tracker #66171, gutaper (gutaper-linux-kernel-bugs) wrote : | #146 |
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/
Is any other quirks exist?
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.