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.