On Sun, Dec 22, 2013 at 09:47:49AM +0200, Denis Turischev wrote:
> On 12/21/2013 01:45 AM, Sarah Sharp wrote:
> > On Fri, Dec 20, 2013 at 12:41:11PM +0200, Denis Turischev wrote:
> >>> 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/
> >
> > 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
On Thu, 2 Jan 2014 16:03:34 -0800
Sarah Sharp <[email protected]> wrote:
> On Sun, Dec 22, 2013 at 09:47:49AM +0200, Denis Turischev wrote:
> > On 12/21/2013 01:45 AM, Sarah Sharp wrote:
> > > On Fri, Dec 20, 2013 at 12:41:11PM +0200, Denis Turischev wrote:
> > >>> 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/
> > >
> > > 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?
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"
>
> 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
On Thu, 2014-01-02 at 16:03 -0800, Sarah Sharp wrote:
> 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.
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
On 01/03/2014 01:03 AM, Sarah Sharp wrote:
> 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
Hi Sarah,
On 01/03/2014 02:03 AM, Sarah Sharp wrote:
> 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
> 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
At Mon, 06 Jan 2014 14:34:28 +0200,
Denis Turischev wrote:
>
> Hi Sarah,
>
> On 01/03/2014 02:03 AM, Sarah Sharp wrote:
> > 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
>
> > 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
On Tue, Jan 07, 2014 at 11:03:00AM +0100, Takashi Iwai wrote:
> At Mon, 06 Jan 2014 14:34:28 +0200,
> Denis Turischev wrote:
> >
> > Hi Sarah,
> >
> > On 01/03/2014 02:03 AM, Sarah Sharp wrote:
> > > 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
> >
> > > 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?
> > 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
On 01/08/2014 01:11 AM, Sarah Sharp wrote:
> 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.