Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1189107
Summary: | shutdown doesn't shutdown | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ralf Corsepius <rc040203> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 21 | CC: | awilliam, gansalmon, itamar, johannbg, jonathan, jsynacek, kernel-maint, lnykryn, madhu.chinakonda, mchehab, msekleta, rc040203, s, systemd-maint, vpavlin, zbyszek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-12-02 08:32:39 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ralf Corsepius
2015-02-04 13:23:23 UTC
Does "systemctl poweroff" result in the same behavior? After the computer is restarted, does "journalctl -b -1" show anything unusual? (In reply to Jan Synacek from comment #1) > Does "systemctl poweroff" result in the same behavior? Yes, it does. "shutdown and reboot" is what I am observing. > After the computer is restarted, does "journalctl -b -1" show anything > unusual? I can't spot anything unusual, but these warnings/errors (Of which I don't know if they are related to this issue at all): ... Feb 04 15:32:18 troy kernel: ACPI Warning: \_SB_.PCI0.RP05.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140926/nsarguments-95) ... Feb 04 16:32:10 troy kernel: acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM I can try the same on another machine, which exposes the same issue, later on today (It's the machine, I am currently working on). (In reply to Ralf Corsepius from comment #2) > I can try the same on another machine, which exposes the same issue, later > on today (It's the machine, I am currently working on). Some more info: * On the second machine (Intel DH87RL Mobo w/ i5-4570), changing "Wake up on LAN from S4/5" to disabled inside of the BIOS/UEFI setup (This mobo has plenty of tunable UEFI settings), seems to have resolved this issue. I don't understand this, but ... Before having modified the UEFI-setting the symptoms have been the same as on the first machine (shutdown and reboot, no matter what I tried). * On the first machine (Lenovo Flex 2-14 notebook w/ i3-4010U), I haven't found any work-around, yet. Neither in its BIOS (Only very few parameters, seemingly no Wake up on LAN or similar) nor elsewhere. Given the comment #3 this sounds like a kernel issue, reassigning. FWIW: * On the Lenovo # sync && poweroff -f works. Anything else I tried, triggers a shut down and reboot. * I can't spot any "Wake up on ..." item in the Lenovo's BIOS/UEFI setup. * Current kernel is kernel-3.18.5-201.fc21 (In reply to Ralf Corsepius from comment #3) > * On the first machine (Lenovo Flex 2-14 notebook w/ i3-4010U) A bewildering observation: "shutdown now" works when having attached an external USB-drive. *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs. Fedora 21 has now been rebased to 3.19.5-200.fc21. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 22, and are still experiencing this issue, please change the version to Fedora 22. If you experience different issues, please open a new bug report for those. This bug persists - Nothing has changed. I had another stab at this one. Googling seems to indicate my issue likely is: https://bugzilla.kernel.org/show_bug.cgi?id=66171 At least adding xhci_hcd.quirks=270336 (i.e. (1<<18 | 1<<13) == (XHCI_SPURIOUS_WAKEUP | XHCI_SPURIOUS_REBOOT) ) to the kernel boot parameters seems to fix it for me. # lspci -vv -s 00:14.0 00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04) (prog-if 30 [XHCI]) Subsystem: Lenovo Device 3978 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 43 Region 0: Memory at f3600000 (64-bit, non-prefetchable) [size=64K] Capabilities: [70] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ Address: 00000000fee00318 Data: 0000 Kernel driver in use: xhci_hcd # uname -a Linux barnaby 4.1.6-200.fc22.x86_64 #1 SMP Mon Aug 17 19:54:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux ralf, can we get 'lspci -nn'? Unless I'm missing it in there somewhere, the PCI ID isn't in the '-vv' output. By Googling for "Intel Corporation 8 Series USB xHCI HC" I get 0x9c31, which is marked as PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI and should already have the quirk applied to it, since c09ec25d3684cad74d851c0f028a495999591279 / 0a939993bff117d3657108ca13b011fc0378aedb . An interesting thing I note is that the XHCI_SPURIOUS_WAKEUP quirk is not actually applied to any systems at all, since: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=b45abacde3d551c6696c6738bef4a1805d0bf27a though before that it was only being applied to HP systems. Can you check if it's the XHCI_SPURIOUS_WAKEUP quirk specifically that fixes things for you - i.e. try with xhci_hcd.quirks=262144 ? (In reply to awilliam from comment #10) > ralf, can we get 'lspci -nn'? Unless I'm missing it in there somewhere, the > PCI ID isn't in the '-vv' output. # lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 09) 00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 09) 00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio Controller [8086:0a0c] (rev 09) 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04) 00:16.0 Communication controller [0780]: Intel Corporation 8 Series HECI #0 [8086:9c3a] (rev 04) 00:1b.0 Audio device [0403]: Intel Corporation 8 Series HD Audio Controller [8086:9c20] (rev 04) 00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 1 [8086:9c10] (rev e4) 00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 3 [8086:9c14] (rev e4) 00:1c.3 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 4 [8086:9c16] (rev e4) 00:1c.4 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 5 [8086:9c18] (rev e4) 00:1f.0 ISA bridge [0601]: Intel Corporation 8 Series LPC Controller [8086:9c43] (rev 04) 00:1f.2 SATA controller [0106]: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] [8086:9c03] (rev 04) 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series SMBus Controller [8086:9c22] (rev 04) 02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter [10ec:b723] 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 10) 04:00.0 3D controller [0302]: NVIDIA Corporation GF117M [GeForce 610M/710M/810M/820M / GT 620M/625M/630M/720M] [10de:1140] (rev a1) (In reply to awilliam from comment #11) > An interesting thing I note is that the XHCI_SPURIOUS_WAKEUP quirk is not > actually applied to any systems at all, since: This remark somewhat confuses me ... XHCI_SPURIOUS_WAKEUP is still applied at other places: # grep -R XHCI_SPURIOUS_WAKEUP drivers/ drivers/usb/host/xhci.h:#define XHCI_SPURIOUS_WAKEUP (1 << 18) drivers/usb/host/xhci-pci.c: if (xhci->quirks & XHCI_SPURIOUS_WAKEUP) drivers/usb/host/xhci.c: if (xhci->quirks & XHCI_SPURIOUS_WAKEUP) drivers/usb/host/xhci.c: if (xhci->quirks & XHCI_SPURIOUS_WAKEUP) And it definitely has an effect (cf. below). > though before that it was only being applied to HP systems. Can you check if > it's the XHCI_SPURIOUS_WAKEUP quirk specifically that fixes things for you - > i.e. try with xhci_hcd.quirks=262144 ? Here is the result: - xhci_hcd.quirks=262144 (== XHCI_SPURIOUS_WAKEUP) works - xhci_hcd.quirks=8192 (== XHCI_SPURIOUS_REBOOT) doesn't work - xhci_hcd.quirks=270336 (== XHCI_SPURIOUS_REBOOT | XHCI_SPURIOUS_WAKEUP) also works. Seems as if I need XHCI_SPURIOUS_WAKEUP. "XHCI_SPURIOUS_WAKEUP is still applied at other places:" None of those places actually *applies* it. The first defines it. The next three implement it. But it's never automatically applied to any hardware any more: the *only* way to use it is to specify it on the kernel command line (whereas when it was first implemented, it was automatically applied to hardware known to be affected by the problem it fixed). Anyhow, it's kind of a side note. I guess at this point we need to engage upstream, I'll try and talk to Josh about the next step tomorrow... This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. I asked labbott if she was getting anywhere with 1257131 recently and she said it was moving forward upstream, I'm not sure if that covers this too - Laura? Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |