Launchpad has imported 139 comments from the remote bug at https://bugzilla.kernel.org/show_bug.cgi?id=66171.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2013-11-29T19:27:28+00:00 ganastasiouGR wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/0 ------------------------------------------------------------------------ On 2013-11-29T19:27:56+00:00 ganastasiouGR wrote: Created attachment 116791 config Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/1 ------------------------------------------------------------------------ On 2013-12-02T07:26:45+00:00 aaron.lu wrote: Does v3.11 have this problem? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/2 ------------------------------------------------------------------------ On 2013-12-02T07:31:16+00:00 ganastasiouGR wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/3 ------------------------------------------------------------------------ On 2013-12-02T07:37:56+00:00 aaron.lu wrote: Can you please do a git bisect to find out the offending commit? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/4 ------------------------------------------------------------------------ On 2013-12-02T10:04:15+00:00 ganastasiouGR wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/5 ------------------------------------------------------------------------ On 2013-12-04T11:32:44+00:00 ganastasiouGR wrote: The offending commit is the following. 638298dc66ea36623dbc2757a24fc2c4ab41b016 is the first bad commit commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 Author: Takashi Iwai <ti...@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 <oneu...@suse.de> Signed-off-by: Takashi Iwai <ti...@suse.de> Signed-off-by: Sarah Sharp <sarah.a.sh...@linux.intel.com> Cc: sta...@vger.kernel.org :040000 040000 6ba54ba0725b8b93e1beff0ed0c8ac0a729f7502 8330c3a748392abc47843a538752d06048ecc0db M drivers Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/6 ------------------------------------------------------------------------ On 2013-12-04T13:07:19+00:00 tianyu.lan wrote: The commit shows the bug is caused by xhci driver and so reassign to USB component. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/7 ------------------------------------------------------------------------ On 2013-12-04T16:29:36+00:00 sarah wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/8 ------------------------------------------------------------------------ On 2013-12-04T16:57:18+00:00 tiwai wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/9 ------------------------------------------------------------------------ On 2013-12-04T17:22:10+00:00 ganastasiouGR wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/10 ------------------------------------------------------------------------ On 2013-12-04T17:25:49+00:00 tiwai wrote: Did you turn on to D0 on all XHCI ports? Also check the actual power state via lspci before testing the power off. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/11 ------------------------------------------------------------------------ On 2013-12-04T17:29:36+00:00 tiwai wrote: Another thing: try to shut down with the reverted kernel but after unloading xhci module. Does this work? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/12 ------------------------------------------------------------------------ On 2013-12-04T17:43:52+00:00 ganastasiouGR wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/13 ------------------------------------------------------------------------ On 2013-12-04T17:46:49+00:00 tiwai wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/14 ------------------------------------------------------------------------ On 2013-12-04T17:49:11+00:00 ganastasiouGR wrote: Glad i helped. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/15 ------------------------------------------------------------------------ On 2013-12-05T07:02:25+00:00 tiwai wrote: 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) { Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/16 ------------------------------------------------------------------------ On 2013-12-05T07:04:46+00:00 tiwai wrote: 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... Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/17 ------------------------------------------------------------------------ On 2013-12-05T08:35:00+00:00 ganastasiouGR wrote: Created attachment 117531 lspci -nv Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/18 ------------------------------------------------------------------------ On 2013-12-08T12:30:59+00:00 tianyu.lan wrote: *** Bug 66551 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/19 ------------------------------------------------------------------------ On 2013-12-09T07:55:00+00:00 dashing.meng wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/20 ------------------------------------------------------------------------ On 2013-12-09T09:42:27+00:00 niklas wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/21 ------------------------------------------------------------------------ On 2013-12-09T10:05:49+00:00 tiwai wrote: (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 ;) Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/22 ------------------------------------------------------------------------ On 2013-12-09T10:08:40+00:00 tiwai wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/23 ------------------------------------------------------------------------ On 2013-12-09T12:04:36+00:00 niklas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/24 ------------------------------------------------------------------------ On 2013-12-09T13:08:13+00:00 tiwai wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/25 ------------------------------------------------------------------------ On 2013-12-09T13:38:55+00:00 niklas wrote: - 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/26 ------------------------------------------------------------------------ On 2013-12-09T13:49:45+00:00 tiwai wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/27 ------------------------------------------------------------------------ On 2013-12-09T14:00:30+00:00 niklas wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/28 ------------------------------------------------------------------------ On 2013-12-09T14:08:07+00:00 tiwai wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/29 ------------------------------------------------------------------------ On 2013-12-09T19:24:32+00:00 niklas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/30 ------------------------------------------------------------------------ On 2013-12-09T22:34:42+00:00 art1 wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/31 ------------------------------------------------------------------------ On 2013-12-10T00:49:54+00:00 sarah wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/32 ------------------------------------------------------------------------ On 2013-12-10T00:53:21+00:00 sarah wrote: a...@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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/33 ------------------------------------------------------------------------ On 2013-12-10T00:54:42+00:00 sarah wrote: a...@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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/34 ------------------------------------------------------------------------ On 2013-12-10T07:08:15+00:00 dashing.meng wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/35 ------------------------------------------------------------------------ On 2013-12-10T07:14:48+00:00 dashing.meng wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/36 ------------------------------------------------------------------------ On 2013-12-10T20:28:38+00:00 niklas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/37 ------------------------------------------------------------------------ On 2013-12-10T20:44:05+00:00 niklas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/38 ------------------------------------------------------------------------ On 2013-12-10T21:06:12+00:00 niklas wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/39 ------------------------------------------------------------------------ On 2013-12-10T21:44:10+00:00 sarah wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/40 ------------------------------------------------------------------------ On 2013-12-10T22:02:02+00:00 niklas wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/41 ------------------------------------------------------------------------ On 2013-12-10T23:13:33+00:00 niklas wrote: 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... Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/42 ------------------------------------------------------------------------ On 2013-12-10T23:26:22+00:00 sarah wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/43 ------------------------------------------------------------------------ On 2013-12-10T23:47:46+00:00 art1 wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/44 ------------------------------------------------------------------------ On 2013-12-11T08:40:30+00:00 niklas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/45 ------------------------------------------------------------------------ On 2013-12-11T08:56:53+00:00 tiwai wrote: Is runtime PM enabled? If yes, what if disabling it via sysfs? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/46 ------------------------------------------------------------------------ On 2013-12-11T11:37:40+00:00 niklas wrote: How do I disable this? /sys/firmware/acpi/pm_profile isn't writable. Also I checked there are no firmware updates available. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/47 ------------------------------------------------------------------------ On 2013-12-12T00:57:04+00:00 dashing.meng wrote: (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.. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/48 ------------------------------------------------------------------------ On 2013-12-12T09:09:38+00:00 niklas wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/49 ------------------------------------------------------------------------ On 2014-01-07T12:28:04+00:00 stephan wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/50 ------------------------------------------------------------------------ On 2014-01-07T22:28:03+00:00 sarah wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/51 ------------------------------------------------------------------------ On 2014-01-07T23:53:49+00:00 niklas wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/52 ------------------------------------------------------------------------ On 2014-01-08T08:39:42+00:00 stephan wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/53 ------------------------------------------------------------------------ On 2014-01-08T08:44:36+00:00 stephan wrote: Sarah: > Who is your motherboard manufacturer? Here are the hardware details: http://www.asrock.com/nettop/Intel/VisionX%20Series%20%28Haswell%29/#Specifications Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/54 ------------------------------------------------------------------------ On 2014-01-08T18:30:32+00:00 tobias wrote: 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... Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/55 ------------------------------------------------------------------------ On 2014-01-08T19:11:14+00:00 niklas wrote: @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). Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/56 ------------------------------------------------------------------------ On 2014-01-10T07:48:50+00:00 tobias wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/57 ------------------------------------------------------------------------ On 2014-01-10T08:50:18+00:00 tiwai wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/58 ------------------------------------------------------------------------ On 2014-01-10T09:31:47+00:00 niklas wrote: ok I can confirm that poweroff works when on battery. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/59 ------------------------------------------------------------------------ On 2014-01-13T00:45:01+00:00 Matti.Kurkela wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/60 ------------------------------------------------------------------------ On 2014-01-15T20:29:03+00:00 tobias wrote: @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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/61 ------------------------------------------------------------------------ On 2014-02-01T23:00:57+00:00 richard.musil wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/62 ------------------------------------------------------------------------ On 2014-02-06T16:53:50+00:00 marcus.husar wrote: Created attachment 124821 XHCI_SPURIOUS_WAKEUP for Panther Point devices from Lenovo Hello, I was also hit by this bug. My device is a Lenovo Thinkpad S531 with Ivy Bridge respectively Panther Point components. The manufacturer of my UEFI/Bios (latest version 1.11) is Lenovo. dmidecode: http://pastebin.com/0Wm2zsCG lspci -vvv: http://pastebin.com/avvCDghE lspci -vvv -n: http://pastebin.com/cu41BxuV Attached is a patch that fixes this bug for me. It is narrowed down to devices from Lenovo. The patch applies cleanly to vanilla kernel 3.13.1 and is tested. It would be great if a similar fix could be applied to the mainline kernel and stable kernels. I have never used anything else than Fedora 20 (initially kernel 3.11.10) on my machine and was never able to power off by doing a normal shutdown. The temporal fix from comment 60 works for me, too. There are several devices from Lenovo which are very similar to mine. Maybe all of them are affected. Some hint if this patch doesn’t work for you: Perhaps you have to rebuild your initramfs. Xhci-hcd.ko was inside my initramfs and after just recompiling the modules in drivers/usb/host I had to rebuild my initramfs. (Re-)building an initramfs with dracut: dracut "" `make kernelrelease` If there is anything else I can do to help fixing this bug, please ask. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/63 ------------------------------------------------------------------------ On 2014-03-11T13:10:50+00:00 michael.korn wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/64 ------------------------------------------------------------------------ On 2014-03-14T17:15:48+00:00 michael.korn wrote: 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 && Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/65 ------------------------------------------------------------------------ On 2014-04-29T16:02:53+00:00 michael.korn wrote: I still suffer under this issue with Ubuntu 14.04. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/66 ------------------------------------------------------------------------ On 2014-05-10T02:39:58+00:00 mail wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/67 ------------------------------------------------------------------------ On 2014-05-12T10:24:20+00:00 michael.korn wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/68 ------------------------------------------------------------------------ On 2014-05-12T11:35:46+00:00 tiwai wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/69 ------------------------------------------------------------------------ On 2014-05-12T14:01:03+00:00 michael.korn wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/70 ------------------------------------------------------------------------ On 2014-05-12T14:04:37+00:00 tiwai wrote: Maybe the option is just missing in your kernel. It's something new. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/71 ------------------------------------------------------------------------ On 2014-05-12T14:56:09+00:00 michael.korn wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/72 ------------------------------------------------------------------------ On 2014-05-13T09:33:20+00:00 michael.korn wrote: 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)? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/73 ------------------------------------------------------------------------ On 2014-05-15T13:46:58+00:00 Matti.Kurkela wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/74 ------------------------------------------------------------------------ On 2014-05-15T13:48:51+00:00 Matti.Kurkela wrote: Created attachment 136201 XHCI_SPURIOUS_WAKEUP for Panther Point devices from Asus & Lenovo Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/75 ------------------------------------------------------------------------ On 2014-05-15T14:57:07+00:00 michael.korn wrote: @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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/76 ------------------------------------------------------------------------ On 2014-05-15T15:05:33+00:00 michael.korn wrote: (In reply to Michael Korn from comment #76) @Matti Kurkela: sorry, please forget my last comment. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/77 ------------------------------------------------------------------------ On 2014-05-16T14:40:49+00:00 Matti.Kurkela wrote: @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... Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/78 ------------------------------------------------------------------------ On 2014-07-29T06:42:39+00:00 maravadue wrote: ...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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/79 ------------------------------------------------------------------------ On 2014-07-29T10:42:38+00:00 Matti.Kurkela wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/80 ------------------------------------------------------------------------ On 2014-07-29T14:27:15+00:00 wulf.richartz wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/81 ------------------------------------------------------------------------ On 2014-07-29T14:35:46+00:00 wulf.richartz wrote: and here the commit: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/usb/host/xhci-pci.c?id=0a939993bff117d3657108ca13b011fc0378aedb Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/82 ------------------------------------------------------------------------ On 2014-07-30T05:54:02+00:00 maravadue wrote: Created attachment 144661 "mario_lspci-nn" Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/83 ------------------------------------------------------------------------ On 2014-07-30T05:54:54+00:00 maravadue wrote: Created attachment 144671 mario_dmidecode Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/84 ------------------------------------------------------------------------ On 2014-08-03T08:51:59+00:00 kitsune wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/85 ------------------------------------------------------------------------ On 2014-08-03T08:52:28+00:00 kitsune wrote: Created attachment 144931 asrock z87 extreme 6 lspci log Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/86 ------------------------------------------------------------------------ On 2014-08-07T15:45:28+00:00 michael.korn wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/87 ------------------------------------------------------------------------ On 2014-08-07T17:16:23+00:00 wulf.richartz wrote: Hopefully ubuntu will also backport the fix for this "fix" :-) Maybe ubuntu-users should open a new issue in ubuntu bugtracker Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/88 ------------------------------------------------------------------------ On 2014-08-08T07:55:56+00:00 Matti.Kurkela wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/89 ------------------------------------------------------------------------ On 2014-08-09T13:26:48+00:00 kitsune wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/90 ------------------------------------------------------------------------ On 2014-08-13T07:24:29+00:00 wulf.richartz wrote: https://bugzilla.kernel.org/show_bug.cgi?id=76291 is fixed with Kernel 3.16, Arch published today Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/91 ------------------------------------------------------------------------ On 2014-08-30T23:11:07+00:00 matthewhague wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/92 ------------------------------------------------------------------------ On 2014-09-02T14:28:21+00:00 maravadue wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/93 ------------------------------------------------------------------------ On 2014-09-02T14:59:45+00:00 wulf.richartz wrote: @mario: you have a new kernel; therefore I guess, ubuntu backported now both patches. You may ask ubuntu Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/94 ------------------------------------------------------------------------ On 2014-09-03T09:04:10+00:00 maravadue wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/95 ------------------------------------------------------------------------ On 2014-09-03T09:16:01+00:00 wulf.richartz wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/96 ------------------------------------------------------------------------ On 2014-09-06T15:11:10+00:00 delobeldavid wrote: 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/ Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/97 ------------------------------------------------------------------------ On 2014-09-11T15:55:03+00:00 delobeldavid wrote: My problem was solved when upgraded from kernel 3.16.1 to 3.16.2. See comment #97. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/98 ------------------------------------------------------------------------ On 2014-10-29T19:37:05+00:00 grantksupport wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/99 ------------------------------------------------------------------------ On 2014-11-03T03:19:36+00:00 grantksupport wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/100 ------------------------------------------------------------------------ On 2014-12-01T16:59:55+00:00 gustik wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/101 ------------------------------------------------------------------------ On 2014-12-11T06:06:30+00:00 saunders.52 wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/102 ------------------------------------------------------------------------ On 2014-12-14T18:28:08+00:00 maarten wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/103 ------------------------------------------------------------------------ On 2014-12-14T21:22:41+00:00 maarten wrote: Ignore my previous post, I don't have an Intel system. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/104 ------------------------------------------------------------------------ On 2015-01-10T17:45:24+00:00 corsseir wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/105 ------------------------------------------------------------------------ On 2015-01-11T00:26:37+00:00 saunders.52 wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/106 ------------------------------------------------------------------------ On 2015-01-12T16:06:40+00:00 corsseir wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/107 ------------------------------------------------------------------------ On 2015-01-12T16:09:38+00:00 corsseir wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/108 ------------------------------------------------------------------------ On 2015-01-12T16:13:29+00:00 corsseir wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/109 ------------------------------------------------------------------------ On 2015-01-12T17:45:39+00:00 corsseir wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/110 ------------------------------------------------------------------------ On 2015-01-13T15:54:17+00:00 corsseir wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/111 ------------------------------------------------------------------------ On 2015-01-14T14:34:53+00:00 michael.korn wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/112 ------------------------------------------------------------------------ On 2015-02-12T21:46:08+00:00 delobeldavid wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/116 ------------------------------------------------------------------------ On 2015-03-11T11:25:32+00:00 jlmaturanag wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/117 ------------------------------------------------------------------------ On 2015-03-11T13:12:23+00:00 corsseir wrote: 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" Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/118 ------------------------------------------------------------------------ On 2015-03-11T15:51:09+00:00 jlmaturanag wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/119 ------------------------------------------------------------------------ On 2015-04-02T05:43:17+00:00 jlmaturanag wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/120 ------------------------------------------------------------------------ On 2015-04-18T09:57:44+00:00 judorange wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/121 ------------------------------------------------------------------------ On 2015-09-18T20:24:48+00:00 mossroy wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/122 ------------------------------------------------------------------------ On 2016-01-21T13:23:15+00:00 jamundso wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/123 ------------------------------------------------------------------------ On 2016-02-19T23:06:31+00:00 smirky wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/124 ------------------------------------------------------------------------ On 2016-03-08T18:59:50+00:00 corsseir wrote: This bug has three years, what kind of info do you need? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/125 ------------------------------------------------------------------------ On 2016-03-08T20:23:12+00:00 alan wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/126 ------------------------------------------------------------------------ On 2016-03-08T21:11:00+00:00 corsseir wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/127 ------------------------------------------------------------------------ On 2016-03-08T21:21:43+00:00 corsseir wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/128 ------------------------------------------------------------------------ On 2016-06-09T08:04:21+00:00 ronan.salmon wrote: > 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/129 ------------------------------------------------------------------------ On 2016-08-25T09:47:53+00:00 yann-externe.soubeyrand wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/130 ------------------------------------------------------------------------ On 2016-08-25T09:48:36+00:00 yann-externe.soubeyrand wrote: Aren't this bug and https://bugzilla.kernel.org/show_bug.cgi?id=76291 duplicates? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/131 ------------------------------------------------------------------------ On 2016-08-25T12:31:25+00:00 alan wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/132 ------------------------------------------------------------------------ On 2016-08-25T12:57:09+00:00 yann-externe.soubeyrand wrote: Created attachment 230181 Add Signed-off-by: line to the previous patch Florian is the colleague of mine who wrote the patch. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/133 ------------------------------------------------------------------------ On 2016-08-25T12:59:11+00:00 yann-externe.soubeyrand wrote: 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)? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/134 ------------------------------------------------------------------------ On 2016-08-25T15:57:38+00:00 alan wrote: I guess in theory be a corporation if it qualifies as a legal entity, but it would normally be a person. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/135 ------------------------------------------------------------------------ On 2016-08-26T09:28:59+00:00 mathias.nyman wrote: 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 <labb...@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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/136 ------------------------------------------------------------------------ On 2016-08-26T10:23:11+00:00 yann-externe.soubeyrand wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/137 ------------------------------------------------------------------------ On 2016-08-31T14:19:52+00:00 francois.cid wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/138 ------------------------------------------------------------------------ On 2017-01-06T22:31:01+00:00 ystianher wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/139 ------------------------------------------------------------------------ On 2017-01-07T01:01:54+00:00 ystianher wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/140 ------------------------------------------------------------------------ On 2018-08-08T15:51:24+00:00 laurent wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts- utopic/+bug/1419355/comments/141 ** Changed in: linux Status: Unknown => Incomplete ** Changed in: linux Importance: Unknown => High ** Bug watch added: Linux Kernel Bug Tracker #66551 https://bugzilla.kernel.org/show_bug.cgi?id=66551 ** Bug watch added: Linux Kernel Bug Tracker #76291 https://bugzilla.kernel.org/show_bug.cgi?id=76291 ** Bug watch added: bugzilla.opensuse.org/ #903560 https://bugzilla.opensuse.org/show_bug.cgi?id=903560 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1419355 Title: System reboots instead of shutdown (if previously unsuspended) (workaround available) To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1419355/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
