Bug 1257131

Proposed as a Blocker for 23-beta by Fedora user robyduck using the blocker tracking app because:

 Tried this on F23-Alpha-Workstation and also F23-Alpha-Xfce, same result. All kernels I tested had the same behaviour, so this violates the following criteria:

Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops.

The issue happens always, it doesn't matter if I use CLI or the desktop offered mechanism.

I tested this with a qemu-kvm guest which runs an up to date Fedora 23 XFCE system.

I can't reproduce the issue; I'm -1 blocker on this since it seems hardware-specific, but more testing is welcome, especially from folks who are able to try F23 on bare metal.

@Giulio: Agree, but it should not happen anyway, IMHO.

I did some tests, but I'm not a QA guy, so perhaps I can help with some requested outputs. In the meanwhile I tried the latest kernel, same issue.
Also, some kernel parameters:
noapic: same as before
acpi=off: with this the system freezes when you shutdown.
blacklisted mei driver (aw this in a recent bug for F20 or so): nothing changed

Just an update, maybe this can help to narrow it down from too generic to a more specific feedback.

This smells a lot like a firmware issue of some kind, in which case it's likely machine specific. It'd be good if we could find someone else with a similar system to test.

Just tried other few things and probably found the issue.
* Setting SELinux to permissive (there was an issue related to that I guess) doesn' resolve it.
* Retried a live image, same rebooting...

So I thought it could be EFI or BIOS related. Then I disabled the xHCI in the Bios instead of smart-auto, and now the system shuts down.

I don't know if this is due to a corrupted xHCI driver, but probably not. Also I never had the USB 3 port active while shutting down.
So this seems not to be related to F23 Alpha or whatever, but to a specific Bios on a specific Intel hardware, if I understand these tests right.

Tried F23 Beta TC1 live on a Lenovo Yoga 3 11 (model 80J8): no problem with shutdown.

Used the USB3 port for the live system...

00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03)

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 61
model name	: Intel(R) Core(TM) M-5Y10c CPU @ 0.80GHz
stepping	: 4
microcode	: 0x1d

So Giulio (thanks) told me about another bug where a user is having the same issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1189107#c9

I tried the workaround mentioned there, xhci_hcd.quirks=270336 to the kernel parameters and I also set xhci to 'smart auto' again, as default.

Result: works here too! Maybe this can help to find a solution to this inconvenience.

Yeah, that's certainly valuable. Trying to guess what kernel folks are going to ask for, can everyone affected please run 'dmidecode' on your affected system as root and attach the output to this bug? Thanks!

Some notes: I think the quirk here is XHCI_SPURIOUS_REBOOT , which was introduced by e95829f474f0db3a4d940cae1423783edd966027 , https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=e95829f474f0db3a4d940cae1423783edd966027 . It looks like c09ec25d3684cad74d851c0f028a495999591279 (by Denis Turischev) applied the quirk to a later hardware generation; looks like the same is probably needed here.

Affected reporters, could we also get 'lspci -nn' output for your systems? Looks like this quirk is usually applied via the XHCI controller's PCI ID...

Can you also please try with both of these variations:

xhci_hcd.quirks=262144
xhci_hcd.quirks=8192

and let us know the results? Thanks!

(In reply to awilliam from comment #10)
These are my results (Lenovo Flex 2-14):

- 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.

[Previously reported in https://bugzilla.redhat.com/show_bug.cgi?id=1189107#c13]

Created attachment 1071204 [details]
dmi.lenovo-flex-2-14

Result of dmidecode > dmi.lenovo-flex-2-14 on my Lenovo Flex 2-14

So here are my results, the same as for Ralf:
- 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.

➜  ~  lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 0b)
00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 0b)
00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio Controller [8086:0a0c] (rev 0b)
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:1d.0 USB controller [0c03]: Intel Corporation 8 Series USB EHCI #1 [8086:9c26] (rev 04)
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]: Intel Corporation Wireless 3160 [8086:08b4] (rev 93)
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 10)

Created attachment 1071344 [details]
dmidecode output

Created attachment 1071435 [details]
Test patch for reboot issue

This adds the quirk directly in the code, feel free to test

(In reply to Laura Abbott from comment #15)
> Created attachment 1071435 [details]
> Test patch for reboot issue
Thanks for the patch.

> This adds the quirk directly in the code, feel free to test
Works for me. 

I am only wondering if the generality (all INTEL_LYNXPOINT_LP_XHCI chipsets) of this patch is correct or if this should be more (board, vendor, BIOS, whatever) specific.

It may need to be more specific. My plan is to follow up with the USB maintainers upstream to see what their thoughts are about making it more specific.

Discussed at 2015-09-10 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-09-10/f23-blocker-review.2015-09-10-16.00.log.txt . Our assessment is this likely doesn't hit enough hardware to qualify for blocker status (it seems like this kind of issue has been hanging around and ping-ponging back and forth upstream for a while) but we'd definitely like to see it fixed, so it's rejected as a blocker but accepted as a freeze exception issue. We will also document it if it is not fixed for Beta.

kernel-4.2.6-300.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-115c302856

kernel-4.2.6-200.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-cd94ad8d7c

kernel-4.2.6-200.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update kernel'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-cd94ad8d7c

kernel-4.2.6-300.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update kernel'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-115c302856

kernel-4.1.13-100.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-f2c534bc12

kernel-4.1.13-100.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update kernel'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-f2c534bc12

kernel-4.2.6-300.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

kernel-4.2.6-200.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

kernel-4.1.13-100.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.