xhci: Switch Intel Lynx Point ports to EHCI on shutdown

PATCH In review Denis Turischev 8 participants 19 messages Dec 19, 2013 – Feb 18, 2014

Subsystems (3)

USB PCI USB xHCI driver

lore

Share & tools

lore

Denis Turischev

author

2013-12-19 16:29 UTC #0 lore raw

The same issue like with Panther Point chipsets. If the USB ports are switched to xHCI on shutdown, the xHCI host will send a spurious interrupt, which will wake the system. Some BIOS have work around for this, but not all.

The bug can be avoided if the USB ports are switched back to EHCI on shutdown.

Signed-off-by Denis Turischev <[email protected]>

drivers/usb/host/xhci-pci.c +3 -2

@@ -91,8 +91,9 @@
 		xhci->quirks |= XHCI_LPM_SUPPORT;
 		xhci->quirks |= XHCI_INTEL_HOST;
 	}
-	if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
-			pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
+	if (pdev->vendor == PCI_VENDOR_ID_INTEL && (
+			(pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) ||
+			(pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI))) {
 		xhci->quirks |= XHCI_EP_LIMIT_QUIRK;
 		xhci->limit_active_eps = 64;
 		xhci->quirks |= XHCI_SW_BW_CHECKING;

include/linux/pci_ids.h +1 -0

@@ -2576,6 +2576,7 @@
 #define PCI_DEVICE_ID_INTEL_COUGARPOINT_LPC_MAX	0x1c5f
 #define PCI_DEVICE_ID_INTEL_PATSBURG_LPC_0	0x1d40
 #define PCI_DEVICE_ID_INTEL_PATSBURG_LPC_1	0x1d41
+#define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI	0x9c31
 #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI	0x1e31
 #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MIN	0x1e40
 #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MAX	0x1e5f

Greg KH

maintainer

2013-12-19 16:38 UTC #1 lore raw

Quoted 28 lines · Denis Turischev

The same issue like with Panther Point chipsets. If the USB ports are switched to xHCI on shutdown, the xHCI host will send a spurious interrupt, which will wake the system. Some BIOS have work around for this, but not all.
The bug can be avoided if the USB ports are switched back to EHCI on shutdown.
Signed-off-by Denis Turischev <[email protected]>
drivers/usb/host/xhci-pci.c +3 -2
@@ -91,8 +91,9 @@
 		xhci->quirks |= XHCI_LPM_SUPPORT;
 		xhci->quirks |= XHCI_INTEL_HOST;
 	}
-	if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
-			pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
+	if (pdev->vendor == PCI_VENDOR_ID_INTEL && (
+			(pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) ||
+			(pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI))) {
 		xhci->quirks |= XHCI_EP_LIMIT_QUIRK;
 		xhci->limit_active_eps = 64;
 		xhci->quirks |= XHCI_SW_BW_CHECKING;

include/linux/pci_ids.h line 2579

Quoted 4 lines

include/linux/pci_ids.h +1 -0

@@ -2576,6 +2576,7 @@
 #define PCI_DEVICE_ID_INTEL_COUGARPOINT_LPC_MAX	0x1c5f
 #define PCI_DEVICE_ID_INTEL_PATSBURG_LPC_0	0x1d40
 #define PCI_DEVICE_ID_INTEL_PATSBURG_LPC_1	0x1d41
+#define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI	0x9c31

Please read the top of this file for why to not add new device ids to it.

And if you really need to do so, please do it in sorted order:

include/linux/pci_ids.h line 2582

Quoted 3 lines

include/linux/pci_ids.h +0 -0

 #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI	0x1e31
 #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MIN	0x1e40
 #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MAX	0x1e5f

Which you didn't do :(

greg k-h

Denis Turischev

author

2013-12-19 17:07 UTC #2 lore raw

PATCH 1/1 xhci: Switch Intel Lynx Point ports to EHCI on shutdown

In reply to Denis Turischev

The bug can be avoided if the USB ports are switched back to EHCI on shutdown.

v1: add new device id locally, not in <linux/pci_ids.h>

Signed-off-by Denis Turischev <[email protected]>

drivers/usb/host/xhci-pci.c +5 -2

@@ -34,6 +34,8 @@
 #define PCI_VENDOR_ID_ETRON		0x1b6f
 #define PCI_DEVICE_ID_ASROCK_P67	0x7023
 
+#define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI	0x9c31
+
 static const char hcd_name[] = "xhci_hcd";
 
 /* called after powerup, by probe or system-pm "wakeup" */

@@ -91,8 +93,9 @@
 		xhci->quirks |= XHCI_LPM_SUPPORT;
 		xhci->quirks |= XHCI_INTEL_HOST;
 	}
-	if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
-			pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
+	if (pdev->vendor == PCI_VENDOR_ID_INTEL && (
+			(pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) ||
+			(pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI))) {
 		xhci->quirks |= XHCI_EP_LIMIT_QUIRK;
 		xhci->limit_active_eps = 64;
 		xhci->quirks |= XHCI_SW_BW_CHECKING;

Sarah Sharp

Tested-by [email protected] on v1 1/1

2013-12-19 18:21 UTC #3 lore raw

This is actually v2.

Quoted 8 lines · Denis Turischev

The same issue like with Panther Point chipsets. If the USB ports are switched to xHCI on shutdown, the xHCI host will send a spurious interrupt, which will wake the system. Some BIOS have work around for this, but not all.
The bug can be avoided if the USB ports are switched back to EHCI on shutdown.
v1: add new device id locally, not in <linux/pci_ids.h>

This line shouldn't go in the patch description.

Quoted 1 line

Signed-off-by Denis Turischev <[email protected]>

Instead, it should go after the --- line, which should be here, but isn't. How did you generate this patch? git format-patch is recommended, or git send-email.

Also, which kernel are you experiencing this issue on? In 3.12, I queued a separate patch to deal with spurious reboot issues on Lynx Point:

commit 638298dc66ea36623dbc2757a24fc2c4ab41b016

Author: Takashi Iwai <[email protected]>
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 <[email protected]>

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Sarah Sharp <[email protected]>

Cc [email protected]

This patch is in 3.12, but a patch to narrow the quirk to only apply HP systems will hit 3.13 shortly:

commit 6962d914f317b119e0db7189199b21ec77a4b3e0

Author: Takashi Iwai <[email protected]>
Date:   Mon Dec 9 14:53:36 2013 +0100

xhci: Limit the spurious wakeup fix only to HP machines

We've got regression reports that my previous fix for spurious wakeups after S5 on HP Haswell machines leads to the automatic reboot at shutdown on some machines. It turned out that the fix for one side triggers another BIOS bug in other side. So, it's exclusive.

Since the original S5 wakeups have been confirmed only on HP machines, it'd be safer to apply it only to limited machines. As a wild guess, limiting to machines with HP PCI SSID should suffice.

This patch should be backported to kernels as old as 3.12, that contain the commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 "xhci: Fix spurious wakeups after S5 on Haswell".

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171

Cc [email protected]

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Sarah Sharp <[email protected]>

Tested-by <[email protected]>

Reported-by Niklas Schnelle <[email protected]>

Reported-by Giorgos <[email protected]>

Reported-by <[email protected]>

So, do you experience the spurious reboots on 3.11? Do they go away in 3.12 with the first patch applied?

Sarah Sharp

Quoted 25 lines

drivers/usb/host/xhci-pci.c +5 -2

@@ -34,6 +34,8 @@
 #define PCI_VENDOR_ID_ETRON		0x1b6f
 #define PCI_DEVICE_ID_ASROCK_P67	0x7023
 
+#define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI	0x9c31
+
 static const char hcd_name[] = "xhci_hcd";
 
 /* called after powerup, by probe or system-pm "wakeup" */

@@ -91,8 +93,9 @@
 		xhci->quirks |= XHCI_LPM_SUPPORT;
 		xhci->quirks |= XHCI_INTEL_HOST;
 	}
-	if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
-			pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
+	if (pdev->vendor == PCI_VENDOR_ID_INTEL && (
+			(pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) ||
+			(pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI))) {
 		xhci->quirks |= XHCI_EP_LIMIT_QUIRK;
 		xhci->limit_active_eps = 64;
 		xhci->quirks |= XHCI_SW_BW_CHECKING;

Denis Turischev

author

2013-12-20 10:41 UTC #4 lore raw

Quoted 33 lines

Also, which kernel are you experiencing this issue on? In 3.12, I queued a separate patch to deal with spurious reboot issues on Lynx Point:
commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
Author: Takashi Iwai <[email protected]>
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."

Quoted 7 lines

Cc Oliver Neukum <[email protected]>
Signed-off-by Takashi Iwai <[email protected]>
Signed-off-by Sarah Sharp <[email protected]>
Cc [email protected]
This patch is in 3.12, but a patch to narrow the quirk to only apply HP systems will hit 3.13 shortly:

Sorry, I indeed tested not on the latest kernel version, Ubuntu 3.13-rc3 has this patch and it works for me.

Denis

Sarah Sharp

2013-12-20 23:45 UTC #5 lore raw

Quoted 7 lines · Denis Turischev

Quoted 5 lines
Also, which kernel are you experiencing this issue on? In 3.12, I queued a separate patch to deal with spurious reboot issues on Lynx Point:
commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
Sorry, I indeed tested not on the latest kernel version, Ubuntu 3.13-rc3 has this patch and it works for me.

What does "Ubuntu 3.13-rc3" mean? Where did you get your kernel from?

Also, do you have an HP system, or is this a different vendor?

Sarah Sharp

Holger Freyther

2013-12-21 16:50 UTC #6 lore raw

Sarah Sharp <sarah.a.sharp <at> linux.intel.com> writes:

Good Afternoon,

Quoted 1 line

Also, do you have an HP system, or is this a different vendor?

for what its worth. I do have an Ivybridge laptop and I do see immediate wake-ups from suspend to ram from time to time. When this happens I do modprobe -r xhci_hcd and the machine goes to sleep as expected. This is on an Acer Aspire S5.

holger

Denis Turischev

author

2013-12-22 07:47 UTC #7 lore raw

In reply to Sarah Sharp

Quoted 10 lines · Sarah Sharp

Quoted 7 lines · Denis Turischev
Quoted 5 lines
Also, which kernel are you experiencing this issue on? In 3.12, I queued a separate patch to deal with spurious reboot issues on Lynx Point:
commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
Sorry, I indeed tested not on the latest kernel version, Ubuntu 3.13-rc3 has this patch and it works for me.
What does "Ubuntu 3.13-rc3" mean? Where did you get your kernel from?

Latest Ubuntu development kernel based on mainline 3.13-rc3.
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc3-trusty/

Quoted 2 lines

Also, do you have an HP system, or is this a different vendor?

No, it's not HP system, it's Compulab's IntensePC-2 with Phoenix BIOS.

Quoted 3 lines

Sarah Sharp

Sarah Sharp

2014-01-03 00:04 UTC #8 lore raw

Quoted 10 lines · Denis Turischev

Quoted 9 lines · Sarah Sharp
Quoted 7 lines · Denis Turischev
Quoted 5 lines
Also, which kernel are you experiencing this issue on? In 3.12, I queued a separate patch to deal with spurious reboot issues on Lynx Point:
commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
Sorry, I indeed tested not on the latest kernel version, Ubuntu 3.13-rc3 has this patch and it works for me.

Quoted 6 lines

Quoted 1 line
What does "Ubuntu 3.13-rc3" mean? Where did you get your kernel from?
Latest Ubuntu development kernel based on mainline 3.13-rc3.
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc3-trusty/
Quoted 2 lines
Also, do you have an HP system, or is this a different vendor?
No, it's not HP system, it's Compulab's IntensePC-2 with Phoenix BIOS.

Ok, that's a bit of an issue then. Your system needs the quirk introduced by commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 "xhci: Fix spurious wakeups after S5 on Haswell". That went into 3.12-rc3. However, in 3.13-rc6, commit 6962d914f317b119e0db7189199b21ec77a4b3e0 "xhci: Limit the spurious wakeup fix only to HP machines" limited the quirk to only HP systems.

That means your system worked fine in 3.13-rc3 (when the quirk was applied broadly), but won't work for 3.13-rc6 (when the quirk was narrowed to HP machines). So we need the quirk to apply to your systems as well.

ISTR that the other folks on Cc (Meng, Niklas, Giorgos, and Art) all had systems that broke when commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 was introduced. For those systems, what vendor was the system, and what BIOS was it running?

Takashi, did the HP systems that needed the quirk have a Phoenix BIOS?

Denis, do all of Compulab's Haswell systems reboot on shutdown? Are they all running a Phoenix BIOS? Can you send me the output of sudo lspci -vvv -s for the xHCI host?

Basically, I'm trying to find a common variable to key off. I suspect BIOS vendor is probably the right thing, instead of system vendor.

Sarah Sharp

littlebat

2014-01-03 03:40 UTC #9 lore raw

Quoted 32 lines · On Thu, 2 Jan 2014 16:03:34 -0800 Sarah Sharp <[email protected]>…

Quoted 10 lines · Denis Turischev
Quoted 9 lines · Sarah Sharp
Quoted 7 lines · Denis Turischev
Quoted 5 lines
Also, which kernel are you experiencing this issue on? In 3.12, I queued a separate patch to deal with spurious reboot issues on Lynx Point:
commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
Sorry, I indeed tested not on the latest kernel version, Ubuntu 3.13-rc3 has this patch and it works for me.
Quoted 8 lines
Quoted 2 lines
What does "Ubuntu 3.13-rc3" mean? Where did you get your kernel from?
Latest Ubuntu development kernel based on mainline 3.13-rc3.
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc3-trusty/
Quoted 2 lines
Also, do you have an HP system, or is this a different vendor?
No, it's not HP system, it's Compulab's IntensePC-2 with Phoenix BIOS.
Ok, that's a bit of an issue then. Your system needs the quirk introduced by commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 "xhci:
Fix spurious wakeups after S5 on Haswell". That went into 3.12-rc3. However, in 3.13-rc6, commit 6962d914f317b119e0db7189199b21ec77a4b3e0 "xhci: Limit the spurious wakeup fix only to HP machines" limited the quirk to only HP systems.
That means your system worked fine in 3.13-rc3 (when the quirk was applied broadly), but won't work for 3.13-rc6 (when the quirk was narrowed to HP machines). So we need the quirk to apply to your systems as well.

Quoted 4 lines

ISTR that the other folks on Cc (Meng, Niklas, Giorgos, and Art) all had systems that broke when commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 was introduced. For those systems, what vendor was the system, and what BIOS was it running?

I'm Meng(littlebat),
Motherboard vendor:
Manufacturer: ASRock
Product Name: Z87 Pro3

BIOS:

Boot into BIOS setup interface, only show:
ASRock UEFI Setup Utility
UIFI Version: Z87 Pro3 P2.20
Chipset Version: C2

Information below gotten from command: sudo dmidecode

# dmidecode 2.12
SMBIOS 2.7 present.
26 structures occupying 1467 bytes.
Table at 0x000EE880.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: P2.20
Release Date: 07/03/2013
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 8192 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) ACPI is supported
USB legacy is supported
BIOS boot specification is supported Targeted content distribution is supported UEFI is supported
BIOS Revision: 4.6

The original bug report of mine is:
https://bugzilla.kernel.org/show_bug.cgi?id=66551

and the bug disappeared when applied patch: commit 6962d914f317b119e0db7189199b21ec77a4b3e0 "xhci: Limit the spurious wakeup fix only to HP machines"

Quoted 11 lines

Takashi, did the HP systems that needed the quirk have a Phoenix BIOS?
Denis, do all of Compulab's Haswell systems reboot on shutdown? Are they all running a Phoenix BIOS? Can you send me the output of sudo lspci -vvv -s for the xHCI host?
Basically, I'm trying to find a common variable to key off. I suspect BIOS vendor is probably the right thing, instead of system vendor.
Sarah Sharp

Oliver Neukum

2014-01-03 18:14 UTC #10 lore raw

In reply to Sarah Sharp

Quoted 14 lines · Sarah Sharp

That means your system worked fine in 3.13-rc3 (when the quirk was applied broadly), but won't work for 3.13-rc6 (when the quirk was narrowed to HP machines). So we need the quirk to apply to your systems
as well.
ISTR that the other folks on Cc (Meng, Niklas, Giorgos, and Art) all had
systems that broke when commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
was introduced. For those systems, what vendor was the system, and what
BIOS was it running?

Quoted 8 lines

Takashi, did the HP systems that needed the quirk have a Phoenix BIOS?
Denis, do all of Compulab's Haswell systems reboot on shutdown? Are they all running a Phoenix BIOS? Can you send me the output of sudo lspci -vvv -s for the xHCI host?
Basically, I'm trying to find a common variable to key off. I suspect BIOS vendor is probably the right thing, instead of system vendor.

The BIOS vendor on HP systems is "Hewlett-Packard" I guess the hope for a single common denominator is futile. It'll have to be a list.

Regards
Oliver

art1

2014-01-03 19:40 UTC #11 lore raw

In reply to Sarah Sharp

Quoted 1 line · Sarah Sharp

ISTR that the other folks on Cc (Meng, Niklas, Giorgos, and Art) all had systems that broke when commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 was introduced. For those systems, what vendor was the system, and what BIOS was it running?

Information from dmidecode:

BIOS Information
Vendor: American Megatrends Inc.

System Information
Manufacturer: To Be Filled By O.E.M.
Product Name: To Be Filled By O.E.M.
Version: To Be Filled By O.E.M.

Base Board Information
Manufacturer: ASRock
Product Name: B85 Pro4

Denis Turischev

author

2014-01-06 12:34 UTC #12 lore raw

In reply to Sarah Sharp

Hi Sarah,

Quoted 3 lines · Sarah Sharp

Denis, do all of Compulab's Haswell systems reboot on shutdown? Are they all running a Phoenix BIOS? Can you send me the output of sudo lspci -vvv -s for the xHCI host?

oem@oem-Intense-PC2 ~ $ sudo lspci -vvv -s 00:14.0
00:14.0 USB controller: Intel Corporation Lynx Point-LP USB xHCI HC (rev 04) (prog-if 30 [XHCI])
Subsystem: Intel Corporation Device 7270
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 59
Region 0: Memory at f0620000 (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: 00000000fee0200c Data: 41b1
Kernel driver in use: xhci_hcd

Quoted 2 lines

Basically, I'm trying to find a common variable to key off. I suspect BIOS vendor is probably the right thing, instead of system vendor.

By the way the quirk introduced by commit e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch PPT ports to EHCI on shutdown." works for Lynx Point as well at least on Intense-PC2. I mean we can add XHCI_SPURIOUS_REBOOT flag that invokes usb_disable_xhci_ports().

May be this solution works for HP and other systems without side effects?

Denis

Takashi Iwai

2014-01-07 10:03 UTC #13 lore raw

At Mon, 06 Jan 2014 14:34:28 +0200,

Quoted 23 lines · Denis Turischev

Hi Sarah,
Quoted 3 lines · Sarah Sharp
Denis, do all of Compulab's Haswell systems reboot on shutdown? Are they all running a Phoenix BIOS? Can you send me the output of sudo lspci -vvv -s for the xHCI host?
oem@oem-Intense-PC2 ~ $ sudo lspci -vvv -s 00:14.0
00:14.0 USB controller: Intel Corporation Lynx Point-LP USB xHCI HC (rev 04) (prog-if 30 [XHCI])
Subsystem: Intel Corporation Device 7270
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 59
Region 0: Memory at f0620000 (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: 00000000fee0200c Data: 41b1
Kernel driver in use: xhci_hcd

Quoted 8 lines

Quoted 2 lines
Basically, I'm trying to find a common variable to key off. I suspect BIOS vendor is probably the right thing, instead of system vendor.
By the way the quirk introduced by commit e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch PPT ports to EHCI on shutdown." works for Lynx Point as well at least on Intense-PC2. I mean we can add XHCI_SPURIOUS_REBOOT flag that invokes usb_disable_xhci_ports().
May be this solution works for HP and other systems without side effects?

No, we already tested it at first, but didn't fix the behavior on HP machines. It was harmless as far as we've tested, though.

Takashi

Sarah Sharp

2014-01-07 23:11 UTC #14 lore raw

Quoted 27 lines · Takashi Iwai

At Mon, 06 Jan 2014 14:34:28 +0200,
Quoted 25 lines · Denis Turischev
Hi Sarah,
Quoted 3 lines · Sarah Sharp
Denis, do all of Compulab's Haswell systems reboot on shutdown? Are they all running a Phoenix BIOS? Can you send me the output of sudo lspci -vvv -s for the xHCI host?
oem@oem-Intense-PC2 ~ $ sudo lspci -vvv -s 00:14.0
00:14.0 USB controller: Intel Corporation Lynx Point-LP USB xHCI HC (rev 04) (prog-if 30 [XHCI])
Subsystem: Intel Corporation Device 7270
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 59
Region 0: Memory at f0620000 (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: 00000000fee0200c Data: 41b1
Kernel driver in use: xhci_hcd
Quoted 2 lines
Basically, I'm trying to find a common variable to key off. I suspect BIOS vendor is probably the right thing, instead of system vendor.

Hmm, since Compulab isn't the subsystem vendor, we can't enable the same HP quirk using that piece of information. We can't enable the quirk to put the host into D3 for all Lynx Point-LP hosts, since that quirk breaks other vendors' systems. Does this impact any Lynx Point (non-LP) systems as well?

So far, two of the other systems that don't react well to the quirk are both ASRock systems with American Megatrends BIOSes, based on info provided by Art and Meng. I can see from Giorgos' posted lspci that his xHCI also lists ASRock as the Subsystem vendor, although I don't know what the BIOS manufacturer is.

Niklas's xHCI subsystem VID:PID is 1558:7410, which is CLEVO/KAPOK Computer Device. Looks like Clevo is a laptop manufacturer.

Giorgos and Niklas, can you post output from sudo dmidecode please?

Quoted 7 lines

Quoted 4 lines
By the way the quirk introduced by commit e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch PPT ports to EHCI on shutdown." works for Lynx Point as well at least on Intense-PC2. I mean we can add XHCI_SPURIOUS_REBOOT flag that invokes usb_disable_xhci_ports().
May be this solution works for HP and other systems without side effects?
No, we already tested it at first, but didn't fix the behavior on HP machines. It was harmless as far as we've tested, though.

Denis, what do you mean by "works for Lynx Point"? Do you mean that adding the quirk to switch the ports on EHCI on shutdown (e95829f474) for the Intense-PC2 *instead of* the commit to put the host in D3 on shutdown (638298dc66) works? Or do you mean you need both patches for your system?

If you only need the quirk to switch the ports to EHCI on shutdown, then we could apply that broadly to Lynx Point LP, and see whether other BIOSes tolerate that quirk.

The alternative would be to turn on the D3 quirk for systems with an HP or Phoenix BIOS, by checking dmi_name_in_vendors() for those strings.

Sarah Sharp

Denis Turischev

author

2014-01-08 12:57 UTC #15 lore raw

Quoted 9 lines · Sarah Sharp

Denis, what do you mean by "works for Lynx Point"? Do you mean that adding the quirk to switch the ports on EHCI on shutdown (e95829f474) for the Intense-PC2 *instead of* the commit to put the host in D3 on shutdown (638298dc66) works? Or do you mean you need both patches for your system?
If you only need the quirk to switch the ports to EHCI on shutdown, then we could apply that broadly to Lynx Point LP, and see whether other BIOSes tolerate that quirk.

Yes, switching the ports on EHCI on shutdown is enough for Intense-PC2. I don't need both patches.

Denis Turischev

author

2014-02-04 11:11 UTC #16 lore raw

PATCH 1/1 xhci: Switch Intel Lynx Point ports to EHCI on shutdown.

In reply to Denis Turischev

The bug can be avoided if the USB ports are switched back to EHCI on shutdown.

Signed-off-by Denis Turischev <[email protected]>

---
 drivers/usb/host/xhci-pci.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/usb/host/xhci-pci.c +2 -0

index 3c898c1..9233d12 100644
@@ -134,6 +134,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
 		 */
 		if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP)
 			xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
+
+		xhci->quirks |= XHCI_SPURIOUS_REBOOT;
 	}
 	if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
 			pdev->device == PCI_DEVICE_ID_ASROCK_P67) {

Signature · 1 line

1.8.1.2

Denis Turischev

author

2014-02-18 07:42 UTC #17 lore raw

PATCH RESEND 1/1 xhci: Switch Intel Lynx Point ports to EHCI on shutdown.

The bug can be avoided if the USB ports are switched back to EHCI on shutdown.

Signed-off-by Denis Turischev <[email protected]>

---
 drivers/usb/host/xhci-pci.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/usb/host/xhci-pci.c +2 -0

index 3c898c1..9233d12 100644
@@ -134,6 +134,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
 		 */
 		if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP)
 			xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
+
+		xhci->quirks |= XHCI_SPURIOUS_REBOOT;
 	}
 	if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
 			pdev->device == PCI_DEVICE_ID_ASROCK_P67) {

-- 1.8.1.2

Sarah Sharp

2014-02-18 18:54 UTC #18 lore raw

Re: [RESEND] [PATCH] xhci: Switch Intel Lynx Point ports to EHCI on shutdown.

Sorry for the delay in reviewing this. It helps me if you don't make the patch in-reply-to a months old thread. :) I'll take a look at this shortly.

Sarah Sharp

Quoted 29 lines · Denis Turischev

The same issue like with Panther Point chipsets. If the USB ports are switched to xHCI on shutdown, the xHCI host will send a spurious interrupt, which will wake the system. Some BIOS have work around for this, but not all. One example is Compulab's mini-desktop, the Intense-PC2.
The bug can be avoided if the USB ports are switched back to EHCI on shutdown.
Signed-off-by Denis Turischev <[email protected]>
---
 drivers/usb/host/xhci-pci.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/usb/host/xhci-pci.c +2 -1
index 3c898c1..9233d12 100644
@@ -134,6 +134,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
 		 */
 		if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP)
 			xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
+
+		xhci->quirks |= XHCI_SPURIOUS_REBOOT;
 	}
 	if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
 			pdev->device == PCI_DEVICE_ID_ASROCK_P67) {
-- 1.8.1.2