Bug 1189107 - shutdown doesn't shutdown
shutdown doesn't shutdown
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
21
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-02-04 08:23 EST by Ralf Corsepius
Modified: 2015-12-02 12:19 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-02 03:32:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ralf Corsepius 2015-02-04 08:23:23 EST
Description of problem:

"shutdown now" doesn't shutdown and halt/poweroff some of my machines. Instead, these machines shutdown and immediately reboot again.

Version-Release number of selected component (if applicable):
systemd-216-17.fc21.x86_64

How reproducible:
Always on some machines.

Steps to Reproduce:
1. As "root" issue
# shutdown now

Actual results:
Machine shuts down, but immediately reboots again.

Expected results:
Machine to shutdown and halt/poweroff

Additional info:
I am only observing this issue on UEFI equipped machines but not on mere BIOS-equipped machines.
Comment 1 Jan Synacek 2015-02-04 09:21:26 EST
Does "systemctl poweroff" result in the same behavior?

After the computer is restarted, does "journalctl -b -1" show anything unusual?
Comment 2 Ralf Corsepius 2015-02-04 09:47:08 EST
(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).
Comment 3 Ralf Corsepius 2015-02-04 13:57:21 EST
(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.
Comment 4 Lennart Poettering 2015-02-04 14:12:33 EST
Given the comment #3 this sounds like a kernel issue, reassigning.
Comment 5 Ralf Corsepius 2015-02-05 01:39:52 EST
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
Comment 6 Ralf Corsepius 2015-03-04 11:35:29 EST
(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.
Comment 7 Fedora Kernel Team 2015-04-28 14:32:11 EDT
*********** 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.
Comment 8 Ralf Corsepius 2015-04-28 17:49:08 EDT
This bug persists - Nothing has changed.
Comment 9 Ralf Corsepius 2015-09-06 12:45:22 EDT
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
Comment 10 Adam Williamson 2015-09-08 01:39:58 EDT
ralf, can we get 'lspci -nn'? Unless I'm missing it in there somewhere, the PCI ID isn't in the '-vv' output.
Comment 11 Adam Williamson 2015-09-08 01:52:06 EDT
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 ?
Comment 12 Ralf Corsepius 2015-09-08 02:04:23 EDT
(In reply to awilliam@redhat.com 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)
Comment 13 Ralf Corsepius 2015-09-08 02:18:50 EDT
(In reply to awilliam@redhat.com 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.
Comment 14 Adam Williamson 2015-09-08 02:24:29 EDT
"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...
Comment 15 Fedora End Of Life 2015-11-04 05:35:47 EST
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.
Comment 16 Adam Williamson 2015-11-04 13:44:53 EST
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?
Comment 17 Fedora End Of Life 2015-12-02 03:32:52 EST
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.

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