[PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications

public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed

* [PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications
@ 2013-03-23 14:33 Rafael J. Wysocki
  2013-03-23 16:22 ` Matthew Garrett
                   ` (3 more replies)
  0 siblings, 4 replies; 24+ messages in thread
From: Rafael J. Wysocki @ 2013-03-23 14:33 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: ACPI Devel Maling List, LKML, Linux PM list, Len Brown,
	Matthew Garrett, Sarah Sharp, Accardi, Kristen C, Huang, Ying,
	linux-pci

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

It turns out that _Lxx control methods provided by some BIOSes clear
the PME Status bit of PCI devices they handle, which means that
pci_acpi_wake_dev() cannot really use that bit to check whether or
not the device has signalled wakeup.

For this reason, make pci_acpi_wake_dev() always attempt to resume
the device it is called for regardless of the device's PME Status bit
value (that bit still has to be cleared if set at this point,
though).

Reported-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/pci/pci-acpi.c |   15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

Index: linux-pm/drivers/pci/pci-acpi.c
===================================================================
--- linux-pm.orig/drivers/pci/pci-acpi.c
+++ linux-pm/drivers/pci/pci-acpi.c
@@ -53,14 +53,15 @@ static void pci_acpi_wake_dev(acpi_handl
 		return;
 	}
 
-	if (!pci_dev->pm_cap || !pci_dev->pme_support
-	     || pci_check_pme_status(pci_dev)) {
-		if (pci_dev->pme_poll)
-			pci_dev->pme_poll = false;
+	/* Clear PME Status if set. */
+	if (pci_dev->pme_support)
+		pci_check_pme_status(pci_dev);
 
-		pci_wakeup_event(pci_dev);
-		pm_runtime_resume(&pci_dev->dev);
-	}
+	if (pci_dev->pme_poll)
+		pci_dev->pme_poll = false;
+
+	pci_wakeup_event(pci_dev);
+	pm_runtime_resume(&pci_dev->dev);
 
 	if (pci_dev->subordinate)
 		pci_pme_wakeup_bus(pci_dev->subordinate);


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications
  2013-03-23 14:33 [PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications Rafael J. Wysocki
@ 2013-03-23 16:22 ` Matthew Garrett
  2013-03-25 16:45 ` Sarah Sharp
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 24+ messages in thread
From: Matthew Garrett @ 2013-03-23 16:22 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Bjorn Helgaas, ACPI Devel Maling List, LKML, Linux PM list,
	Len Brown, Sarah Sharp, Accardi, Kristen C, Huang, Ying,
	linux-pci

Looks good to me.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications
  2013-03-23 14:33 [PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications Rafael J. Wysocki
  2013-03-23 16:22 ` Matthew Garrett
@ 2013-03-25 16:45 ` Sarah Sharp
  2013-03-25 22:34   ` Rafael J. Wysocki
  2013-03-28 17:10 ` [Resend][PATCH] " Rafael J. Wysocki
       [not found] ` <51548C9E.9090703@fold.natur.cuni.cz>
  3 siblings, 1 reply; 24+ messages in thread
From: Sarah Sharp @ 2013-03-25 16:45 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Bjorn Helgaas, ACPI Devel Maling List, LKML, Linux PM list,
	Len Brown, Matthew Garrett, Accardi, Kristen C, Huang, Ying,
	linux-pci

On Sat, Mar 23, 2013 at 03:33:03PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> It turns out that _Lxx control methods provided by some BIOSes clear
> the PME Status bit of PCI devices they handle, which means that
> pci_acpi_wake_dev() cannot really use that bit to check whether or
> not the device has signalled wakeup.
> 
> For this reason, make pci_acpi_wake_dev() always attempt to resume
> the device it is called for regardless of the device's PME Status bit
> value (that bit still has to be cleared if set at this point,
> though).
> 
> Reported-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Should this be marked for stable?  I had this issue on 3.7 and 3.8 as
well.

Sarah

> ---
>  drivers/pci/pci-acpi.c |   15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> Index: linux-pm/drivers/pci/pci-acpi.c
> ===================================================================
> --- linux-pm.orig/drivers/pci/pci-acpi.c
> +++ linux-pm/drivers/pci/pci-acpi.c
> @@ -53,14 +53,15 @@ static void pci_acpi_wake_dev(acpi_handl
>  		return;
>  	}
>  
> -	if (!pci_dev->pm_cap || !pci_dev->pme_support
> -	     || pci_check_pme_status(pci_dev)) {
> -		if (pci_dev->pme_poll)
> -			pci_dev->pme_poll = false;
> +	/* Clear PME Status if set. */
> +	if (pci_dev->pme_support)
> +		pci_check_pme_status(pci_dev);
>  
> -		pci_wakeup_event(pci_dev);
> -		pm_runtime_resume(&pci_dev->dev);
> -	}
> +	if (pci_dev->pme_poll)
> +		pci_dev->pme_poll = false;
> +
> +	pci_wakeup_event(pci_dev);
> +	pm_runtime_resume(&pci_dev->dev);
>  
>  	if (pci_dev->subordinate)
>  		pci_pme_wakeup_bus(pci_dev->subordinate);
> 

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications
  2013-03-25 16:45 ` Sarah Sharp
@ 2013-03-25 22:34   ` Rafael J. Wysocki
  0 siblings, 0 replies; 24+ messages in thread
From: Rafael J. Wysocki @ 2013-03-25 22:34 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Bjorn Helgaas, ACPI Devel Maling List, LKML, Linux PM list,
	Len Brown, Matthew Garrett, Accardi, Kristen C, Huang, Ying,
	linux-pci

On Monday, March 25, 2013 09:45:51 AM Sarah Sharp wrote:
> On Sat, Mar 23, 2013 at 03:33:03PM +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > 
> > It turns out that _Lxx control methods provided by some BIOSes clear
> > the PME Status bit of PCI devices they handle, which means that
> > pci_acpi_wake_dev() cannot really use that bit to check whether or
> > not the device has signalled wakeup.
> > 
> > For this reason, make pci_acpi_wake_dev() always attempt to resume
> > the device it is called for regardless of the device's PME Status bit
> > value (that bit still has to be cleared if set at this point,
> > though).
> > 
> > Reported-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Should this be marked for stable?  I had this issue on 3.7 and 3.8 as
> well.

Yes, it probably should, but that's the maintainer's call.

Thanks,
Rafael


> > ---
> >  drivers/pci/pci-acpi.c |   15 ++++++++-------
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> > 
> > Index: linux-pm/drivers/pci/pci-acpi.c
> > ===================================================================
> > --- linux-pm.orig/drivers/pci/pci-acpi.c
> > +++ linux-pm/drivers/pci/pci-acpi.c
> > @@ -53,14 +53,15 @@ static void pci_acpi_wake_dev(acpi_handl
> >  		return;
> >  	}
> >  
> > -	if (!pci_dev->pm_cap || !pci_dev->pme_support
> > -	     || pci_check_pme_status(pci_dev)) {
> > -		if (pci_dev->pme_poll)
> > -			pci_dev->pme_poll = false;
> > +	/* Clear PME Status if set. */
> > +	if (pci_dev->pme_support)
> > +		pci_check_pme_status(pci_dev);
> >  
> > -		pci_wakeup_event(pci_dev);
> > -		pm_runtime_resume(&pci_dev->dev);
> > -	}
> > +	if (pci_dev->pme_poll)
> > +		pci_dev->pme_poll = false;
> > +
> > +	pci_wakeup_event(pci_dev);
> > +	pm_runtime_resume(&pci_dev->dev);
> >  
> >  	if (pci_dev->subordinate)
> >  		pci_pme_wakeup_bus(pci_dev->subordinate);
> > 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* [Resend][PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications
  2013-03-23 14:33 [PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications Rafael J. Wysocki
  2013-03-23 16:22 ` Matthew Garrett
  2013-03-25 16:45 ` Sarah Sharp
@ 2013-03-28 17:10 ` Rafael J. Wysocki
  2013-03-28 21:07   ` [Update][PATCH] " Rafael J. Wysocki
       [not found] ` <51548C9E.9090703@fold.natur.cuni.cz>
  3 siblings, 1 reply; 24+ messages in thread
From: Rafael J. Wysocki @ 2013-03-28 17:10 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: ACPI Devel Maling List, LKML, Linux PM list, Len Brown,
	Matthew Garrett, Sarah Sharp, Accardi, Kristen C, Huang, Ying,
	linux-pci

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

It turns out that the _Lxx control methods provided by some BIOSes
clear the PME Status bit of PCI devices they handle, which means that
pci_acpi_wake_dev() cannot really use that bit to check whether or
not the device has signalled wakeup.

The symptom of the problem is, for example, that when a PCI USB
controller is affected, then plugging in a new USB device into one of
the controller's ports will not wake up the controller, which should
happen.

For this reason, make pci_acpi_wake_dev() always attempt to resume
the device it is called for regardless of the device's PME Status bit
value (that bit still has to be cleared if set at this point,
though).

Reported-and-tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: 3.7+ <stable@vger.kernel.org>
---
 drivers/pci/pci-acpi.c |   15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

Index: linux-pm/drivers/pci/pci-acpi.c
===================================================================
--- linux-pm.orig/drivers/pci/pci-acpi.c
+++ linux-pm/drivers/pci/pci-acpi.c
@@ -53,14 +53,15 @@ static void pci_acpi_wake_dev(acpi_handl
 		return;
 	}
 
-	if (!pci_dev->pm_cap || !pci_dev->pme_support
-	     || pci_check_pme_status(pci_dev)) {
-		if (pci_dev->pme_poll)
-			pci_dev->pme_poll = false;
+	/* Clear PME Status if set. */
+	if (pci_dev->pme_support)
+		pci_check_pme_status(pci_dev);
 
-		pci_wakeup_event(pci_dev);
-		pm_runtime_resume(&pci_dev->dev);
-	}
+	if (pci_dev->pme_poll)
+		pci_dev->pme_poll = false;
+
+	pci_wakeup_event(pci_dev);
+	pm_runtime_resume(&pci_dev->dev);
 
 	if (pci_dev->subordinate)
 		pci_pme_wakeup_bus(pci_dev->subordinate);


^ permalink raw reply	[flat|nested] 24+ messages in thread

* [Update][PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications
  2013-03-28 17:10 ` [Resend][PATCH] " Rafael J. Wysocki
@ 2013-03-28 21:07   ` Rafael J. Wysocki
  2013-03-29 15:05     ` Martin Mokrejs
  2013-04-03 22:38     ` Bjorn Helgaas
  0 siblings, 2 replies; 24+ messages in thread
From: Rafael J. Wysocki @ 2013-03-28 21:07 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: ACPI Devel Maling List, LKML, Linux PM list, Len Brown,
	Matthew Garrett, Sarah Sharp, Accardi, Kristen C, Huang, Ying,
	linux-pci

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Subject: PCI / ACPI: Always resume devices on ACPI wakeup notifications

It turns out that the _Lxx control methods provided by some BIOSes
clear the PME Status bit of PCI devices they handle, which means that
pci_acpi_wake_dev() cannot really use that bit to check whether or
not the device has signalled wakeup.

One symptom of the problem is, for example, that when an affected PCI
USB controller is runtime-suspended, then plugging in a new USB device
into one of the controller's ports will not wake up the controller,
which should happen.

For this reason, make pci_acpi_wake_dev() always attempt to resume
the device it is called for regardless of the device's PME Status bit
value (that bit still has to be cleared if set at this point,
though).

Reported-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: 3.7+ <stable@vger.kernel.org>
---

The changelog in this version is slightly better than in the previous one, IMHO.

Thanks,
Rafael

---
 drivers/pci/pci-acpi.c |   15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

Index: linux-pm/drivers/pci/pci-acpi.c
===================================================================
--- linux-pm.orig/drivers/pci/pci-acpi.c
+++ linux-pm/drivers/pci/pci-acpi.c
@@ -53,14 +53,15 @@ static void pci_acpi_wake_dev(acpi_handl
 		return;
 	}

-	if (!pci_dev->pm_cap || !pci_dev->pme_support
-	     || pci_check_pme_status(pci_dev)) {
-		if (pci_dev->pme_poll)
-			pci_dev->pme_poll = false;
+	/* Clear PME Status if set. */
+	if (pci_dev->pme_support)
+		pci_check_pme_status(pci_dev);

-		pci_wakeup_event(pci_dev);
-		pm_runtime_resume(&pci_dev->dev);
-	}
+	if (pci_dev->pme_poll)
+		pci_dev->pme_poll = false;
+
+	pci_wakeup_event(pci_dev);
+	pm_runtime_resume(&pci_dev->dev);

 	if (pci_dev->subordinate)
 		pci_pme_wakeup_bus(pci_dev->subordinate);

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications
  2013-03-28 21:07   ` [Update][PATCH] " Rafael J. Wysocki
@ 2013-03-29 15:05     ` Martin Mokrejs
  2013-03-29 16:05       ` Sarah Sharp
  2013-03-29 21:34       ` Rafael J. Wysocki
  2013-04-03 22:38     ` Bjorn Helgaas
  1 sibling, 2 replies; 24+ messages in thread
From: Martin Mokrejs @ 2013-03-29 15:05 UTC (permalink / raw)
  To: Rafael J. Wysocki, Bjorn Helgaas
  Cc: ACPI Devel Maling List, LKML, Linux PM list, Len Brown,
	Matthew Garrett, Sarah Sharp, Accardi, Kristen C, Huang, Ying,
	linux-pci

Hi,
  I applied this patches over 3.8.3 hoping it will fix my issue under
thread: "Re: 3.8.2: xhci port is dead until pcieport PME# goes to disabled"
but unfortunately, it is even worse! Now, although lsusb -v nor lsusb -vv do
wakeup the XHCI port but it falls asleep immediately, more quickly than I am
able to plug a device into the socket. To get a device working in the USB3 socket
I need to plug it in, run lsusb -vv and then it is recognized.

Without the patch, the 'lsusb -vv' woke up the port (PME# disabled happened
on both 1c.4 and 0b:00.0) and I had unlimited time to find some USB device
around and to plug it into the slot.


  I noticed this message some while after a bootup (no external USB devices were
connected to the laptop, neither into USB2 socket nor into USB3.0 sockets) before
I started to do the tests:

[   36.594171] xhci_hcd 0000:0b:00.0: xhci_suspend: stopping port polling.
[   36.594202] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
[   36.594247] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_suspend: 0
[   36.594349] xhci_hcd 0000:0b:00.0: PME# enabled
[   36.703695] r8169 0000:05:00.0 eth0: link down
[   37.098299] microcode: CPU0 updated to revision 0x28, date = 2012-04-24
[   37.098941] microcode: CPU1 updated to revision 0x28, date = 2012-04-24
[   37.098944] perf_event_intel: PEBS enabled due to microcode update
[   38.343029] r8169 0000:05:00.0 eth0: link up
[   39.094944] r8169 0000:05:00.0 eth0: link down
[   41.492768] r8169 0000:05:00.0 eth0: link up
[   62.782910] xhci_hcd 0000:0b:00.0: Poll event ring: 4294943584
[   62.782938] xhci_hcd 0000:0b:00.0: op reg status = 0xffffffff
[   62.782939] xhci_hcd 0000:0b:00.0: HW died, polling stopped.
[   88.754183] pcieport 0000:00:1c.0: PME# enabled
[   88.764182] xhci_hcd 0000:0b:00.0: PME# disabled
[   88.764192] xhci_hcd 0000:0b:00.0: enabling bus mastering
[   88.764206] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
[   88.764242] xhci_hcd 0000:0b:00.0: Port Status Change Event for port 2
[   88.764246] xhci_hcd 0000:0b:00.0: resume root hub
[   88.764259] xhci_hcd 0000:0b:00.0: handle_port_status: starting port polling.
[   88.764276] xhci_hcd 0000:0b:00.0: xhci_resume: starting port polling.
[   88.764281] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_resume: 0


What "HW died? Why 1c.0 is here? What is this device actually doing?

00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Bus: primary=00, secondary=03, subordinate=04, sec-latency=0
        I/O behind bridge: 0000f000-00000fff
        Memory behind bridge: fff00000-000fffff
        Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 128 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
                LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <16us
                        ClockPM- Surprise- LLActRep+ BwNot-
                LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
                        Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
                SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
                        Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
                SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
                        Changed: MRL- PresDet- LinkState-
                RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
                RootCap: CRSVisible-
                RootSta: PME ReqID 0000, PMEStatus- PMEPending-
                DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
                Address: 00000000  Data: 0000
        Capabilities: [90] Subsystem: Dell Device 04b3
        Capabilities: [a0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME-
        Kernel driver in use: pcieport





Nevertheless, I went to check if if the USB3 socket dies after first unplug of device
or not anymore thanks to the patch being tested:

I plugged into the USB3.0 socket a mouse, it worked. Around its unplug I got:

[   94.954779] hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
[   94.954795] hub 3-0:1.0: hub_suspend
[   94.954802] usb usb3: bus auto-suspend, wakeup 1
[   94.954817] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
[   94.954835] xhci_hcd 0000:0b:00.0: xhci_suspend: stopping port polling.
[   94.954857] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
[   94.954898] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_suspend: 0
[   94.954983] xhci_hcd 0000:0b:00.0: PME# enabled
[  169.622513] hub 2-1:1.0: state 7 ports 8 chg 0000 evt 0004
[  169.623057] hub 2-1:1.0: port 2, status 0101, change 0001, 12 Mb/s
[  169.777012] hub 2-1:1.0: debounce: port 2: total 100ms stable 100ms status 0x101
[  169.856992] usb 2-1.2: new low-speed USB device number 4 using ehci-pci

and the port was dead, no matter what "lsusb -v or -vv" options I tried. At about
[  169.622513] I plugged the mouse into a USB2.0 socket (do not know if that is 1a.0 or 1d.0).

# lspci -tv
-[0000:00]-+-00.0  Intel Corporation 2nd Generation Core Processor Family DRAM Controller
           +-02.0  Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller
           +-16.0  Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1
           +-1a.0  Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2
           +-1b.0  Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller
           +-1c.0-[03-04]--
           +-1c.1-[05-06]----00.0  Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller
           +-1c.3-[09-0a]----00.0  Intel Corporation Centrino Wireless-N 1030 [Rainbow Peak]
           +-1c.4-[0b-0c]----00.0  Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller
           +-1c.7-[11-16]----00.0  Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller
           +-1d.0  Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1
           +-1f.0  Intel Corporation HM67 Express Chipset Family LPC Controller
           +-1f.2  Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller
           \-1f.3  Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller
#


 Why isn't the PME# enabled/disabled reported for the USB2.0 port of the
same laptop? There I can plugin a device many times in and out and not a single PME# line is
spitted by dmesg.
# grep . /sys/bus/pci/devices/*/power/control
/sys/bus/pci/devices/0000:00:00.0/power/control:auto
/sys/bus/pci/devices/0000:00:02.0/power/control:auto
/sys/bus/pci/devices/0000:00:16.0/power/control:auto
/sys/bus/pci/devices/0000:00:1a.0/power/control:auto
/sys/bus/pci/devices/0000:00:1b.0/power/control:auto
/sys/bus/pci/devices/0000:00:1c.0/power/control:auto
/sys/bus/pci/devices/0000:00:1c.1/power/control:auto
/sys/bus/pci/devices/0000:00:1c.3/power/control:auto
/sys/bus/pci/devices/0000:00:1c.4/power/control:auto
/sys/bus/pci/devices/0000:00:1c.7/power/control:auto
/sys/bus/pci/devices/0000:00:1d.0/power/control:auto
/sys/bus/pci/devices/0000:00:1f.0/power/control:auto
/sys/bus/pci/devices/0000:00:1f.2/power/control:auto
/sys/bus/pci/devices/0000:00:1f.3/power/control:auto
/sys/bus/pci/devices/0000:05:00.0/power/control:auto
/sys/bus/pci/devices/0000:09:00.0/power/control:auto
/sys/bus/pci/devices/0000:0b:00.0/power/control:auto
/sys/bus/pci/devices/0000:11:00.0/power/control:auto
# grep . /sys/bus/pci/devices/*/power/runtime_status
/sys/bus/pci/devices/0000:00:00.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:00:02.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:16.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:00:1a.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1b.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1c.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:00:1c.1/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1c.3/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1c.4/power/runtime_status:suspended
/sys/bus/pci/devices/0000:00:1c.7/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1d.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1f.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1f.2/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1f.3/power/runtime_status:suspended
/sys/bus/pci/devices/0000:05:00.0/power/runtime_status:active
/sys/bus/pci/devices/0000:09:00.0/power/runtime_status:active
/sys/bus/pci/devices/0000:0b:00.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:11:00.0/power/runtime_status:active
#

If I run lsusb -vv it does (with the problematic patch):

[ 1760.414086] pcieport 0000:00:1c.4: PME# disabled
[ 1760.434314] xhci_hcd 0000:0b:00.0: PME# disabled
[ 1760.434327] xhci_hcd 0000:0b:00.0: enabling bus mastering
[ 1760.434338] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
[ 1760.434360] xhci_hcd 0000:0b:00.0: Port Status Change Event for port 2
[ 1760.434363] xhci_hcd 0000:0b:00.0: resume root hub
[ 1760.434367] xhci_hcd 0000:0b:00.0: handle_port_status: starting port polling.
[ 1760.434378] xhci_hcd 0000:0b:00.0: xhci_resume: starting port polling.
[ 1760.434383] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_resume: 0
[ 1760.434388] usb usb3: usb auto-resume
[ 1760.434407] hub 3-0:1.0: hub_resume
[ 1760.434439] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
[ 1760.434440] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
[ 1760.434464] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x202a0
[ 1760.434465] xhci_hcd 0000:0b:00.0: Get port status returned 0x10100
[ 1760.434492] xhci_hcd 0000:0b:00.0: clear port connect change, actual port 1 status  = 0x2a0
[ 1760.434642] usb usb4: usb wakeup-resume
[ 1760.434646] usb usb4: usb auto-resume
[ 1760.434661] hub 4-0:1.0: hub_resume
[ 1760.434683] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
[ 1760.434684] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
[ 1760.434710] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
[ 1760.434711] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
[ 1760.434727] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000
[ 1760.434757] xhci_hcd 0000:0b:00.0: set port remote wake mask, actual port 0 status  = 0xe0002a0
[ 1760.434784] xhci_hcd 0000:0b:00.0: set port remote wake mask, actual port 1 status  = 0xe0002a0
[ 1760.434791] hub 4-0:1.0: hub_suspend
[ 1760.434796] usb usb4: bus auto-suspend, wakeup 1
[ 1760.434807] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
[ 1760.553734] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
[ 1760.553751] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000
[ 1760.574793] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
[ 1760.574794] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
[ 1760.575300] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
[ 1760.575301] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
[ 1760.576768] hub 3-0:1.0: hub_suspend
[ 1760.576774] usb usb3: bus auto-suspend, wakeup 1
[ 1760.576789] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
[ 1760.576802] xhci_hcd 0000:0b:00.0: xhci_suspend: stopping port polling.
[ 1760.576817] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
[ 1760.576851] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_suspend: 0
[ 1760.576938] xhci_hcd 0000:0b:00.0: PME# enabled
[ 1760.613874] xhci_hcd 0000:0b:00.0: PME# disabled
[ 1760.613884] xhci_hcd 0000:0b:00.0: enabling bus mastering
[ 1760.613895] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
[ 1760.613914] xhci_hcd 0000:0b:00.0: xhci_resume: starting port polling.
[ 1760.613922] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
[ 1760.613924] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_resume: 0
[ 1760.613929] usb usb4: usb auto-resume
[ 1760.613945] hub 4-0:1.0: hub_resume
[ 1760.613981] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
[ 1760.613982] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
[ 1760.614010] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
[ 1760.614012] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
[ 1760.614038] usb usb3: usb wakeup-resume
[ 1760.614040] usb usb3: usb auto-resume
[ 1760.614059] hub 3-0:1.0: hub_resume
[ 1760.614080] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
[ 1760.614081] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
[ 1760.614104] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
[ 1760.614105] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
[ 1760.614122] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000
[ 1760.614126] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000
[ 1760.614134] hub 3-0:1.0: hub_suspend
[ 1760.614139] usb usb3: bus auto-suspend, wakeup 1
[ 1760.614152] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
[ 1760.623621] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
[ 1760.646744] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
[ 1760.646746] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
[ 1760.647281] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
[ 1760.647283] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
[ 1760.657965] xhci_hcd 0000:0b:00.0: set port remote wake mask, actual port 0 status  = 0xe0002a0
[ 1760.657992] xhci_hcd 0000:0b:00.0: set port remote wake mask, actual port 1 status  = 0xe0002a0
[ 1760.658000] hub 4-0:1.0: hub_suspend
[ 1760.658004] usb usb4: bus auto-suspend, wakeup 1
[ 1760.658015] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
[ 1760.658027] xhci_hcd 0000:0b:00.0: xhci_suspend: stopping port polling.
[ 1760.658042] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
[ 1760.658074] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_suspend: 0
[ 1760.658159] xhci_hcd 0000:0b:00.0: PME# enabled
[ 1760.683743] pcieport 0000:00:1c.4: PME# enabled



Hope this helps,
Martin




Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Subject: PCI / ACPI: Always resume devices on ACPI wakeup notifications
> 
> It turns out that the _Lxx control methods provided by some BIOSes
> clear the PME Status bit of PCI devices they handle, which means that
> pci_acpi_wake_dev() cannot really use that bit to check whether or
> not the device has signalled wakeup.
> 
> One symptom of the problem is, for example, that when an affected PCI
> USB controller is runtime-suspended, then plugging in a new USB device
> into one of the controller's ports will not wake up the controller,
> which should happen.
> 
> For this reason, make pci_acpi_wake_dev() always attempt to resume
> the device it is called for regardless of the device's PME Status bit
> value (that bit still has to be cleared if set at this point,
> though).
> 
> Reported-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
> Cc: 3.7+ <stable@vger.kernel.org>
> ---
> 
> The changelog in this version is slightly better than in the previous one, IMHO.
> 
> Thanks,
> Rafael
> 
> ---
>  drivers/pci/pci-acpi.c |   15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> Index: linux-pm/drivers/pci/pci-acpi.c
> ===================================================================
> --- linux-pm.orig/drivers/pci/pci-acpi.c
> +++ linux-pm/drivers/pci/pci-acpi.c
> @@ -53,14 +53,15 @@ static void pci_acpi_wake_dev(acpi_handl
>  		return;
>  	}
>  
> -	if (!pci_dev->pm_cap || !pci_dev->pme_support
> -	     || pci_check_pme_status(pci_dev)) {
> -		if (pci_dev->pme_poll)
> -			pci_dev->pme_poll = false;
> +	/* Clear PME Status if set. */
> +	if (pci_dev->pme_support)
> +		pci_check_pme_status(pci_dev);
>  
> -		pci_wakeup_event(pci_dev);
> -		pm_runtime_resume(&pci_dev->dev);
> -	}
> +	if (pci_dev->pme_poll)
> +		pci_dev->pme_poll = false;
> +
> +	pci_wakeup_event(pci_dev);
> +	pm_runtime_resume(&pci_dev->dev);
>  
>  	if (pci_dev->subordinate)
>  		pci_pme_wakeup_bus(pci_dev->subordinate);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications
  2013-03-29 15:05     ` Martin Mokrejs
@ 2013-03-29 16:05       ` Sarah Sharp
  2013-03-29 17:11         ` Martin Mokrejs
  2013-03-29 21:37         ` Rafael J. Wysocki
  2013-03-29 21:34       ` Rafael J. Wysocki
  1 sibling, 2 replies; 24+ messages in thread
From: Sarah Sharp @ 2013-03-29 16:05 UTC (permalink / raw)
  To: Martin Mokrejs
  Cc: Rafael J. Wysocki, Bjorn Helgaas, ACPI Devel Maling List, LKML,
	Linux PM list, Len Brown, Matthew Garrett, Accardi, Kristen C,
	Huang, Ying, linux-pci

On Fri, Mar 29, 2013 at 04:05:54PM +0100, Martin Mokrejs wrote:
> [   36.594171] xhci_hcd 0000:0b:00.0: xhci_suspend: stopping port polling.
> [   36.594202] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
> [   36.594247] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_suspend: 0
> [   36.594349] xhci_hcd 0000:0b:00.0: PME# enabled
> [   36.703695] r8169 0000:05:00.0 eth0: link down
> [   37.098299] microcode: CPU0 updated to revision 0x28, date = 2012-04-24
> [   37.098941] microcode: CPU1 updated to revision 0x28, date = 2012-04-24
> [   37.098944] perf_event_intel: PEBS enabled due to microcode update
> [   38.343029] r8169 0000:05:00.0 eth0: link up
> [   39.094944] r8169 0000:05:00.0 eth0: link down
> [   41.492768] r8169 0000:05:00.0 eth0: link up
> [   62.782910] xhci_hcd 0000:0b:00.0: Poll event ring: 4294943584
> [   62.782938] xhci_hcd 0000:0b:00.0: op reg status = 0xffffffff
> [   62.782939] xhci_hcd 0000:0b:00.0: HW died, polling stopped.
> [   88.754183] pcieport 0000:00:1c.0: PME# enabled
> [   88.764182] xhci_hcd 0000:0b:00.0: PME# disabled
> [   88.764192] xhci_hcd 0000:0b:00.0: enabling bus mastering
> [   88.764206] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
> [   88.764242] xhci_hcd 0000:0b:00.0: Port Status Change Event for port 2
> [   88.764246] xhci_hcd 0000:0b:00.0: resume root hub
> [   88.764259] xhci_hcd 0000:0b:00.0: handle_port_status: starting port polling.
> [   88.764276] xhci_hcd 0000:0b:00.0: xhci_resume: starting port polling.
> [   88.764281] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_resume: 0
> 
> 
> What "HW died? Why 1c.0 is here? What is this device actually doing?

It's harmless.  The xHCI polling loop to debug the host registers and
rings simply notices that the registers are reading as all ffs.  I
believe that's normal when a PCI device is in D3.  I just haven't had
time to make a patch to disable the polling loop when the host is suspended.

So, for now, ignore the "HW died, polling stopped." messages.

> Nevertheless, I went to check if if the USB3 socket dies after first unplug of device
> or not anymore thanks to the patch being tested:
> 
> I plugged into the USB3.0 socket a mouse, it worked. Around its unplug I got:
> 
> [   94.954779] hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
> [   94.954795] hub 3-0:1.0: hub_suspend
> [   94.954802] usb usb3: bus auto-suspend, wakeup 1
> [   94.954817] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
> [   94.954835] xhci_hcd 0000:0b:00.0: xhci_suspend: stopping port polling.
> [   94.954857] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
> [   94.954898] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_suspend: 0
> [   94.954983] xhci_hcd 0000:0b:00.0: PME# enabled
> [  169.622513] hub 2-1:1.0: state 7 ports 8 chg 0000 evt 0004
> [  169.623057] hub 2-1:1.0: port 2, status 0101, change 0001, 12 Mb/s
> [  169.777012] hub 2-1:1.0: debounce: port 2: total 100ms stable 100ms status 0x101
> [  169.856992] usb 2-1.2: new low-speed USB device number 4 using ehci-pci
> 
> and the port was dead, no matter what "lsusb -v or -vv" options I tried. At about
> [  169.622513] I plugged the mouse into a USB2.0 socket (do not know if that is 1a.0 or 1d.0).

All right, I wonder if the USB core/xHCI driver is forgetting to clear a
port status change bit after the device is unplugged.  That can cause
the xHCI host to not give us a port status change event later (and thus
no PME).  Looking at the logs later, it doesn't seem like we do this
though.

> If I run lsusb -vv it does (with the problematic patch):
> 
> [ 1760.414086] pcieport 0000:00:1c.4: PME# disabled
> [ 1760.434314] xhci_hcd 0000:0b:00.0: PME# disabled
> [ 1760.434327] xhci_hcd 0000:0b:00.0: enabling bus mastering
> [ 1760.434338] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
> [ 1760.434360] xhci_hcd 0000:0b:00.0: Port Status Change Event for port 2

Ok, so the xHCI driver *is* getting a port status change event, and thus
must have gotten a PME.  So the PCI layer is doing its job.

> [ 1760.434363] xhci_hcd 0000:0b:00.0: resume root hub
> [ 1760.434367] xhci_hcd 0000:0b:00.0: handle_port_status: starting port polling.
> [ 1760.434378] xhci_hcd 0000:0b:00.0: xhci_resume: starting port polling.
> [ 1760.434383] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_resume: 0
> [ 1760.434388] usb usb3: usb auto-resume
> [ 1760.434407] hub 3-0:1.0: hub_resume
> [ 1760.434439] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
> [ 1760.434440] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
> [ 1760.434464] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x202a0
> [ 1760.434465] xhci_hcd 0000:0b:00.0: Get port status returned 0x10100
> [ 1760.434492] xhci_hcd 0000:0b:00.0: clear port connect change, actual port 1 status  = 0x2a0

Odd.  The port status shows there's no device connected, but there was a
connect change:

sarah@xanatos:~$ ./decode-port-status 0x202a0
port status = 0x0202a0
 bit  0     (CCS)          0x0, device not connected
 bit  1     (PED)          0x0, port disabled
 bit  3     (OCA)          0x0, no over-current condition
 bit  4     (PR)           0x0, port not in reset
 bits 8:5   (PLS)          0x5, link is in the RxDetect state
 bit  9     (PP)           0x1, port power on
 bits 13:10 (speed)        0x0, Undefined
 bits 15:14 (indicators)   0x0, port indicators are off
 bit  17    (CSC)          0x1, connect change
 bit  18    (PEC)          0x0, no port enable/disable change
 bit  19    (WRC)          0x0, no warm port reset change
 bit  20    (OCC)          0x0, no over-current change
 bit  21    (PRC)          0x0, no port reset change
 bit  22    (PLC)          0x0, no port link change
 bit  23    (CEC)          0x0, no port config error change
 bit  25    (WCE)          0x0, wake on connect disabled
 bit  26    (WDE)          0x0, wake on disconnect disabled
 bit  27    (WOE)          0x0, wake on over-current enable disabled
 bit  30    (DR)           0x0, device is permanently attached

RxDetect is the "I'm looking for a USB device" port state.

> [ 1760.434642] usb usb4: usb wakeup-resume
> [ 1760.434646] usb usb4: usb auto-resume
> [ 1760.434661] hub 4-0:1.0: hub_resume
> [ 1760.434683] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
> [ 1760.434684] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
> [ 1760.434710] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
> [ 1760.434711] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
> [ 1760.434727] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000
> [ 1760.434757] xhci_hcd 0000:0b:00.0: set port remote wake mask, actual port 0 status  = 0xe0002a0
> [ 1760.434784] xhci_hcd 0000:0b:00.0: set port remote wake mask, actual port 1 status  = 0xe0002a0
> [ 1760.434791] hub 4-0:1.0: hub_suspend
> [ 1760.434796] usb usb4: bus auto-suspend, wakeup 1
> [ 1760.434807] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
> [ 1760.553734] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
> [ 1760.553751] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000
> [ 1760.574793] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
> [ 1760.574794] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
> [ 1760.575300] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
> [ 1760.575301] xhci_hcd 0000:0b:00.0: Get port status returned 0x100

sarah@xanatos:~$ ./decode-port-status 0x2a0
port status = 0x0002a0
 bit  0     (CCS)          0x0, device not connected
 bit  1     (PED)          0x0, port disabled
 bit  3     (OCA)          0x0, no over-current condition
 bit  4     (PR)           0x0, port not in reset
 bits 8:5   (PLS)          0x5, link is in the RxDetect state
 bit  9     (PP)           0x1, port power on
 bits 13:10 (speed)        0x0, Undefined
 bits 15:14 (indicators)   0x0, port indicators are off
 bit  17    (CSC)          0x0, no connect change
 bit  18    (PEC)          0x0, no port enable/disable change
 bit  19    (WRC)          0x0, no warm port reset change
 bit  20    (OCC)          0x0, no over-current change
 bit  21    (PRC)          0x0, no port reset change
 bit  22    (PLC)          0x0, no port link change
 bit  23    (CEC)          0x0, no port config error change
 bit  25    (WCE)          0x0, wake on connect disabled
 bit  26    (WDE)          0x0, wake on disconnect disabled
 bit  27    (WOE)          0x0, wake on over-current enable disabled
 bit  30    (DR)           0x0, device is permanently attached

Nope, your host really isn't reporting there's a device connected
*at all*.  That's just broken hardware, and there's really nothing
software can do if the hardware isn't reporting connect events, even
with polling.

It also doesn't sound like the other TI redriver bug.  That bug only
effected USB 3.0 ports, and when lsusb was run, we would find the port
in Compliance Mode.  This is the host simply not reporting the USB 2.0
port connect at all.

Maybe if we completely disable PCI runtime PM for your host, we can work
around this bug?

Can you send me the output of `sudo lspci -vvv -n` again?

Sarah Sharp

> [ 1760.576768] hub 3-0:1.0: hub_suspend
> [ 1760.576774] usb usb3: bus auto-suspend, wakeup 1
> [ 1760.576789] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
> [ 1760.576802] xhci_hcd 0000:0b:00.0: xhci_suspend: stopping port polling.
> [ 1760.576817] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
> [ 1760.576851] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_suspend: 0
> [ 1760.576938] xhci_hcd 0000:0b:00.0: PME# enabled
> [ 1760.613874] xhci_hcd 0000:0b:00.0: PME# disabled
> [ 1760.613884] xhci_hcd 0000:0b:00.0: enabling bus mastering
> [ 1760.613895] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
> [ 1760.613914] xhci_hcd 0000:0b:00.0: xhci_resume: starting port polling.
> [ 1760.613922] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
> [ 1760.613924] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_resume: 0
> [ 1760.613929] usb usb4: usb auto-resume
> [ 1760.613945] hub 4-0:1.0: hub_resume
> [ 1760.613981] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
> [ 1760.613982] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
> [ 1760.614010] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
> [ 1760.614012] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
> [ 1760.614038] usb usb3: usb wakeup-resume
> [ 1760.614040] usb usb3: usb auto-resume
> [ 1760.614059] hub 3-0:1.0: hub_resume
> [ 1760.614080] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
> [ 1760.614081] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
> [ 1760.614104] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
> [ 1760.614105] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
> [ 1760.614122] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000
> [ 1760.614126] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000
> [ 1760.614134] hub 3-0:1.0: hub_suspend
> [ 1760.614139] usb usb3: bus auto-suspend, wakeup 1
> [ 1760.614152] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
> [ 1760.623621] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
> [ 1760.646744] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
> [ 1760.646746] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
> [ 1760.647281] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
> [ 1760.647283] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
> [ 1760.657965] xhci_hcd 0000:0b:00.0: set port remote wake mask, actual port 0 status  = 0xe0002a0
> [ 1760.657992] xhci_hcd 0000:0b:00.0: set port remote wake mask, actual port 1 status  = 0xe0002a0
> [ 1760.658000] hub 4-0:1.0: hub_suspend
> [ 1760.658004] usb usb4: bus auto-suspend, wakeup 1
> [ 1760.658015] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
> [ 1760.658027] xhci_hcd 0000:0b:00.0: xhci_suspend: stopping port polling.
> [ 1760.658042] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
> [ 1760.658074] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_suspend: 0
> [ 1760.658159] xhci_hcd 0000:0b:00.0: PME# enabled
> [ 1760.683743] pcieport 0000:00:1c.4: PME# enabled

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications
  2013-03-29 16:05       ` Sarah Sharp
@ 2013-03-29 17:11         ` Martin Mokrejs
  2013-03-29 18:16           ` Martin Mokrejs
  2013-03-29 21:37         ` Rafael J. Wysocki
  1 sibling, 1 reply; 24+ messages in thread
From: Martin Mokrejs @ 2013-03-29 17:11 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Rafael J. Wysocki, Bjorn Helgaas, ACPI Devel Maling List, LKML,
	Linux PM list, Len Brown, Matthew Garrett, Accardi, Kristen C,
	Huang, Ying, linux-pci

Sarah,
  please let me know if you feel the test was screwed by laptop-mode-tools
kicking in, although I believed they were not running while I was on AC power.
I was testing under these conditions:

vostro ~ # grep . /sys/bus/pci/devices/*/power/control
/sys/bus/pci/devices/0000:00:00.0/power/control:auto
/sys/bus/pci/devices/0000:00:02.0/power/control:auto
/sys/bus/pci/devices/0000:00:16.0/power/control:auto
/sys/bus/pci/devices/0000:00:1a.0/power/control:auto
/sys/bus/pci/devices/0000:00:1b.0/power/control:auto
/sys/bus/pci/devices/0000:00:1c.0/power/control:auto
/sys/bus/pci/devices/0000:00:1c.1/power/control:auto
/sys/bus/pci/devices/0000:00:1c.3/power/control:auto
/sys/bus/pci/devices/0000:00:1c.4/power/control:auto
/sys/bus/pci/devices/0000:00:1c.7/power/control:auto
/sys/bus/pci/devices/0000:00:1d.0/power/control:auto
/sys/bus/pci/devices/0000:00:1f.0/power/control:auto
/sys/bus/pci/devices/0000:00:1f.2/power/control:auto
/sys/bus/pci/devices/0000:00:1f.3/power/control:auto
/sys/bus/pci/devices/0000:05:00.0/power/control:auto
/sys/bus/pci/devices/0000:09:00.0/power/control:auto
/sys/bus/pci/devices/0000:0b:00.0/power/control:auto
/sys/bus/pci/devices/0000:11:00.0/power/control:auto
vostro ~ # grep . /sys/bus/pci/devices/*/power/runtime_status
/sys/bus/pci/devices/0000:00:00.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:00:02.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:16.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:00:1a.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1b.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1c.0/power/runtime_status:suspended
/sys/bus/pci/devices/0000:00:1c.1/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1c.3/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1c.4/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1c.7/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1d.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1f.0/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1f.2/power/runtime_status:active
/sys/bus/pci/devices/0000:00:1f.3/power/runtime_status:suspended
/sys/bus/pci/devices/0000:05:00.0/power/runtime_status:active
/sys/bus/pci/devices/0000:09:00.0/power/runtime_status:active
/sys/bus/pci/devices/0000:0b:00.0/power/runtime_status:active
/sys/bus/pci/devices/0000:11:00.0/power/runtime_status:active
vostro ~ # 

My apologies if that twisted the test and thanks for you detailed explanations.

I will spot below, however, a few questions.

Sarah Sharp wrote:
> On Fri, Mar 29, 2013 at 04:05:54PM +0100, Martin Mokrejs wrote:

> 
>> Nevertheless, I went to check if if the USB3 socket dies after first unplug of device
>> or not anymore thanks to the patch being tested:
>>
>> I plugged into the USB3.0 socket a mouse, it worked. Around its unplug I got:
>>
>> [   94.954779] hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
>> [   94.954795] hub 3-0:1.0: hub_suspend
>> [   94.954802] usb usb3: bus auto-suspend, wakeup 1
>> [   94.954817] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
>> [   94.954835] xhci_hcd 0000:0b:00.0: xhci_suspend: stopping port polling.
>> [   94.954857] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
>> [   94.954898] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_suspend: 0
>> [   94.954983] xhci_hcd 0000:0b:00.0: PME# enabled
>> [  169.622513] hub 2-1:1.0: state 7 ports 8 chg 0000 evt 0004
>> [  169.623057] hub 2-1:1.0: port 2, status 0101, change 0001, 12 Mb/s
>> [  169.777012] hub 2-1:1.0: debounce: port 2: total 100ms stable 100ms status 0x101
>> [  169.856992] usb 2-1.2: new low-speed USB device number 4 using ehci-pci
>>
>> and the port was dead, no matter what "lsusb -v or -vv" options I tried. At about
>> [  169.622513] I plugged the mouse into a USB2.0 socket (do not know if that is 1a.0 or 1d.0).
> 
> All right, I wonder if the USB core/xHCI driver is forgetting to clear a
> port status change bit after the device is unplugged.  That can cause
> the xHCI host to not give us a port status change event later (and thus
> no PME).  Looking at the logs later, it doesn't seem like we do this
> though.
> 
>> If I run lsusb -vv it does (with the problematic patch):
>>
>> [ 1760.414086] pcieport 0000:00:1c.4: PME# disabled
>> [ 1760.434314] xhci_hcd 0000:0b:00.0: PME# disabled
>> [ 1760.434327] xhci_hcd 0000:0b:00.0: enabling bus mastering
>> [ 1760.434338] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
>> [ 1760.434360] xhci_hcd 0000:0b:00.0: Port Status Change Event for port 2
> 
> Ok, so the xHCI driver *is* getting a port status change event, and thus
> must have gotten a PME.  So the PCI layer is doing its job.
> 
>> [ 1760.434363] xhci_hcd 0000:0b:00.0: resume root hub
>> [ 1760.434367] xhci_hcd 0000:0b:00.0: handle_port_status: starting port polling.
>> [ 1760.434378] xhci_hcd 0000:0b:00.0: xhci_resume: starting port polling.
>> [ 1760.434383] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_resume: 0
>> [ 1760.434388] usb usb3: usb auto-resume
>> [ 1760.434407] hub 3-0:1.0: hub_resume
>> [ 1760.434439] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
>> [ 1760.434440] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
>> [ 1760.434464] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x202a0
>> [ 1760.434465] xhci_hcd 0000:0b:00.0: Get port status returned 0x10100
>> [ 1760.434492] xhci_hcd 0000:0b:00.0: clear port connect change, actual port 1 status  = 0x2a0
> 
> Odd.  The port status shows there's no device connected, but there was a
> connect change:
> 
> sarah@xanatos:~$ ./decode-port-status 0x202a0
> port status = 0x0202a0
>  bit  0     (CCS)          0x0, device not connected
>  bit  1     (PED)          0x0, port disabled
>  bit  3     (OCA)          0x0, no over-current condition
>  bit  4     (PR)           0x0, port not in reset
>  bits 8:5   (PLS)          0x5, link is in the RxDetect state
>  bit  9     (PP)           0x1, port power on
>  bits 13:10 (speed)        0x0, Undefined
>  bits 15:14 (indicators)   0x0, port indicators are off
>  bit  17    (CSC)          0x1, connect change
>  bit  18    (PEC)          0x0, no port enable/disable change
>  bit  19    (WRC)          0x0, no warm port reset change
>  bit  20    (OCC)          0x0, no over-current change
>  bit  21    (PRC)          0x0, no port reset change
>  bit  22    (PLC)          0x0, no port link change
>  bit  23    (CEC)          0x0, no port config error change
>  bit  25    (WCE)          0x0, wake on connect disabled
>  bit  26    (WDE)          0x0, wake on disconnect disabled
>  bit  27    (WOE)          0x0, wake on over-current enable disabled
>  bit  30    (DR)           0x0, device is permanently attached
> 
> RxDetect is the "I'm looking for a USB device" port state.
> 
>> [ 1760.434642] usb usb4: usb wakeup-resume
>> [ 1760.434646] usb usb4: usb auto-resume
>> [ 1760.434661] hub 4-0:1.0: hub_resume
>> [ 1760.434683] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
>> [ 1760.434684] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
>> [ 1760.434710] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
>> [ 1760.434711] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
>> [ 1760.434727] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000
>> [ 1760.434757] xhci_hcd 0000:0b:00.0: set port remote wake mask, actual port 0 status  = 0xe0002a0
>> [ 1760.434784] xhci_hcd 0000:0b:00.0: set port remote wake mask, actual port 1 status  = 0xe0002a0
>> [ 1760.434791] hub 4-0:1.0: hub_suspend
>> [ 1760.434796] usb usb4: bus auto-suspend, wakeup 1
>> [ 1760.434807] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
>> [ 1760.553734] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
>> [ 1760.553751] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000
>> [ 1760.574793] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
>> [ 1760.574794] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
>> [ 1760.575300] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
>> [ 1760.575301] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
> 
> sarah@xanatos:~$ ./decode-port-status 0x2a0
> port status = 0x0002a0
>  bit  0     (CCS)          0x0, device not connected
>  bit  1     (PED)          0x0, port disabled
>  bit  3     (OCA)          0x0, no over-current condition
>  bit  4     (PR)           0x0, port not in reset
>  bits 8:5   (PLS)          0x5, link is in the RxDetect state
>  bit  9     (PP)           0x1, port power on
>  bits 13:10 (speed)        0x0, Undefined
>  bits 15:14 (indicators)   0x0, port indicators are off
>  bit  17    (CSC)          0x0, no connect change
>  bit  18    (PEC)          0x0, no port enable/disable change
>  bit  19    (WRC)          0x0, no warm port reset change
>  bit  20    (OCC)          0x0, no over-current change
>  bit  21    (PRC)          0x0, no port reset change
>  bit  22    (PLC)          0x0, no port link change
>  bit  23    (CEC)          0x0, no port config error change
>  bit  25    (WCE)          0x0, wake on connect disabled
>  bit  26    (WDE)          0x0, wake on disconnect disabled
>  bit  27    (WOE)          0x0, wake on over-current enable disabled
>  bit  30    (DR)           0x0, device is permanently attached
> 
> Nope, your host really isn't reporting there's a device connected
> *at all*.  That's just broken hardware, and there's really nothing
> software can do if the hardware isn't reporting connect events, even
> with polling.
> 
> It also doesn't sound like the other TI redriver bug.  That bug only
> effected USB 3.0 ports, and when lsusb was run, we would find the port
> in Compliance Mode.  This is the host simply not reporting the USB 2.0
> port connect at all.
> 
> Maybe if we completely disable PCI runtime PM for your host, we can work
> around this bug?

I am not sure I understand what you mean. The proposed patch makes the
situation worse. To be able to use the xHCI port for second and later times,
I have to plugin a device and run 'lsusb -vv' to get the device detected
before the "port" falls asleep. This is NOT necessary for the SandyBridge
USB2.0 port under same conditions (well, regarding the disclaimer I made
on the very top of this message, from the other thread where Ying found that
I had laptop-mode-tools installed I realized that laptop-mode-tools
fiddled with xHCI port while NOT with EHCI port. Please correct me if
I was wrong. So, please re-consider your above conclusions. Most importantly,
I don not understand the "This is the host simply not reporting the USB 2.0
port connect at all.". Did you mean "USB 3.0 instead"?

Other than that, I am ready to file a bug report to Dell's Pro Support site
but from my last experience they were quite clue-less regarding the broken
"express card PresDet detection". ;-) I bet they could replace the TexasInstruments
USB3.0 card which is a separate thing in the laptop. At least I could get
the TI hardware which has hopefully fixed the redriver. ;-)
How could I reproduce the issue in Win7 which are on the laptop? I mean,
the change the PM handling to reproduce what I got on linux under laptop-mode-tools?
;)

> 
> Can you send me the output of `sudo lspci -vvv -n` again?

Will send after I reboot into a clean state and re-test the behavior while
laptop-mode-tools are gone. Maybe the issue will remain anyways.
So so far I tested effectively as under:

echo auto > /sys/bus/pci/devices/0000:0b:00.0/power/control

and without laptop-mode-tools trickery I should be now testing under

echo on > /sys/bus/pci/devices/0000:0b:00.0/power/control

, right?

Thank you,
Martin

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications
  2013-03-29 17:11         ` Martin Mokrejs
@ 2013-03-29 18:16           ` Martin Mokrejs
  0 siblings, 0 replies; 24+ messages in thread
From: Martin Mokrejs @ 2013-03-29 18:16 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Rafael J. Wysocki, Bjorn Helgaas, ACPI Devel Maling List, LKML,
	Linux PM list, Len Brown, Matthew Garrett, Accardi, Kristen C,
	Huang, Ying, linux-pci

[-- Attachment #1: Type: text/plain, Size: 9237 bytes --]

So, I re-tested again with the patch and 3.8.3 but without laptop-mode-tools.
The xHCI port works fine provided /sys/bus/pci/devices/0000:0b:00.0/power/control
is set to on and /sys/bus/pci/devices/0000:00:1c.4/power/control also to on.
If I set parent 1c.4 to auto, it gets suspended and the port seems dead until
a device is in and I wake it using lsusb -vv. There must be a bug in linux so
that it cannot overcome upstream 1c.4 sleeping while willing to access 0b:00.
Or more likely, that upstream root port should be prevented to fall asleep, right?


# lspci -tv
-[0000:00]-+-00.0  Intel Corporation 2nd Generation Core Processor Family DRAM Controller
           +-02.0  Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller
           +-16.0  Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1
           +-1a.0  Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2
           +-1b.0  Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller
           +-1c.0-[03-04]--
           +-1c.1-[05-06]----00.0  Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller
           +-1c.3-[09-0a]----00.0  Intel Corporation Centrino Wireless-N 1030 [Rainbow Peak]
           +-1c.4-[0b-0c]----00.0  Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller
           +-1c.7-[11-16]----00.0  Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller
           +-1d.0  Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1
           +-1f.0  Intel Corporation HM67 Express Chipset Family LPC Controller
           +-1f.2  Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller
           \-1f.3  Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller
#



I have attached the lspci -vvv -n.

Interestingly, maybe, the TI xHCI controller ended up after my tests
changed. I booted up with all devices with power/control set to on
due to laptop-mode-tools uninstalled. I fiddled with the echo commands
tweaking 1c.4 and 0b:00 but in the end set both back to "on". However,
below is some diff. Don't know what that means. Maybe because I tried
to write '0', 'off', 'none' to the control file? ;-)

 00:1c.4 0604: 8086:1c18 (rev b5) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Bus: primary=00, secondary=0b, subordinate=0c, sec-latency=0
        I/O behind bridge: 0000f000-00000fff
        Memory behind bridge: f7d00000-f7dfffff
        Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 128 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
                LnkCap: Port #5, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us
                        ClockPM- Surprise- LLActRep+ BwNot-
                LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt+
                SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
                        Slot #4, PowerLimit 10.000W; Interlock- NoCompl+
                SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
                        Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
                SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
                        Changed: MRL- PresDet- LinkState+
                RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
                RootCap: CRSVisible-
-               RootSta: PME ReqID 0000, PMEStatus- PMEPending-
+               RootSta: PME ReqID 0b00, PMEStatus- PMEPending-
                DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
                LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
                Address: 00000000  Data: 0000
        Capabilities: [90] Subsystem: 1028:04b3
        Capabilities: [a0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: pcieport


 0b:00.0 0c03: 104c:8241 (rev 02) (prog-if 30 [XHCI])
        Subsystem: 1028:04b3
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at f7d00000 (64-bit, non-prefetchable) [size=64K]
        Region 2: Memory at f7d10000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=100mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] MSI: Enable- Count=1/8 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [70] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 1024 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
                LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
                        ClockPM+ Surprise- LLActRep- BwNot-
                LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
                LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [c0] MSI-X: Enable+ Count=8 Masked-
                Vector table: BAR=2 offset=00000000
                PBA: BAR=2 offset=00001000
        Capabilities: [100 v2] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
-               CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
+               CESta:  RxErr- BadTLP- BadDLLP+ Rollover- Timeout- NonFatalErr+
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
        Capabilities: [150 v1] Device Serial Number 08-00-28-00-00-20-00-00
        Kernel driver in use: xhci_hcd




[-- Attachment #2: lspci_vvvn_initial.txt --]
[-- Type: text/plain, Size: 31820 bytes --]

00:00.0 0600: 8086:0104 (rev 09)
	Subsystem: 1028:04b3
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information: Len=0c <?>

00:02.0 0300: 8086:0126 (rev 09) (prog-if 00 [VGA controller])
	Subsystem: 1028:04b3
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 47
	Region 0: Memory at f6800000 (64-bit, non-prefetchable) [size=4M]
	Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at f000 [size=64]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0300c  Data: 4162
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [a4] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: i915

00:16.0 0780: 8086:1c3a (rev 04)
	Subsystem: 1028:04b3
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at f7f0a000 (64-bit, non-prefetchable) [size=16]
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [8c] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000

00:1a.0 0c03: 8086:1c2d (rev 05) (prog-if 20 [EHCI])
	Subsystem: 1028:04b3
	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 16
	Region 0: Memory at f7f08000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] 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: [58] Debug port: BAR=1 offset=00a0
	Capabilities: [98] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ehci-pci

00:1b.0 0403: 8086:1c20 (rev 05)
	Subsystem: 1028:04b3
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 45
	Region 0: Memory at f7f00000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000fee0300c  Data: 4142
	Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE- FLReset+
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed- WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=01
			Status:	NegoPending- InProgress-
		VC1:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=1 ArbSelect=Fixed TC/VC=22
			Status:	NegoPending- InProgress-
	Capabilities: [130 v1] Root Complex Link
		Desc:	PortNumber=0f ComponentID=00 EltType=Config
		Link0:	Desc:	TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
			Addr:	00000000fed1c000
	Kernel driver in use: snd_hda_intel

00:1c.0 0604: 8086:1c10 (rev b5) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=03, subordinate=04, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <16us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
			Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
	Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
		Address: 00000000  Data: 0000
	Capabilities: [90] Subsystem: 1028:04b3
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pcieport

00:1c.1 0604: 8086:1c12 (rev b5) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=05, subordinate=06, sec-latency=0
	I/O behind bridge: 0000e000-0000efff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000f1100000-00000000f11fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #2, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
			Slot #1, PowerLimit 10.000W; Interlock- NoCompl+
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
			Changed: MRL- PresDet- LinkState+
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
	Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
		Address: 00000000  Data: 0000
	Capabilities: [90] Subsystem: 1028:04b3
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pcieport

00:1c.3 0604: 8086:1c16 (rev b5) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=09, subordinate=0a, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: f7e00000-f7efffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
			Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
			Changed: MRL- PresDet- LinkState+
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
	Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
		Address: 00000000  Data: 0000
	Capabilities: [90] Subsystem: 1028:04b3
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pcieport

00:1c.4 0604: 8086:1c18 (rev b5) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=0b, subordinate=0c, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: f7d00000-f7dfffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #5, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt+
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
			Slot #4, PowerLimit 10.000W; Interlock- NoCompl+
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
			Changed: MRL- PresDet- LinkState+
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
	Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
		Address: 00000000  Data: 0000
	Capabilities: [90] Subsystem: 1028:04b3
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pcieport

00:1c.7 0604: 8086:1c1e (rev b5) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=11, subordinate=16, sec-latency=0
	I/O behind bridge: 0000c000-0000dfff
	Memory behind bridge: f6c00000-f7cfffff
	Prefetchable memory behind bridge: 00000000f0000000-00000000f10fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #8, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
			Slot #7, PowerLimit 10.000W; Interlock- NoCompl+
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
			Changed: MRL- PresDet- LinkState-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
		DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
	Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
		Address: 00000000  Data: 0000
	Capabilities: [90] Subsystem: 1028:04b3
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pcieport

00:1d.0 0c03: 8086:1c26 (rev 05) (prog-if 20 [EHCI])
	Subsystem: 1028:04b3
	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 23
	Region 0: Memory at f7f07000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] 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: [58] Debug port: BAR=1 offset=00a0
	Capabilities: [98] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ehci-pci

00:1f.0 0601: 8086:1c4b (rev 05)
	Subsystem: 1028:04b3
	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
	Capabilities: [e0] Vendor Specific Information: Len=0c <?>
	Kernel driver in use: lpc_ich

00:1f.2 0106: 8086:1c03 (rev 05) (prog-if 01 [AHCI 1.0])
	Subsystem: 1028:04b3
	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 B routed to IRQ 40
	Region 0: I/O ports at f0b0 [size=8]
	Region 1: I/O ports at f0a0 [size=4]
	Region 2: I/O ports at f090 [size=8]
	Region 3: I/O ports at f080 [size=4]
	Region 4: I/O ports at f060 [size=32]
	Region 5: Memory at f7f06000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0300c  Data: 4191
	Capabilities: [70] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
	Capabilities: [b0] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ahci

00:1f.3 0c05: 8086:1c22 (rev 05)
	Subsystem: 1028:04b3
	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-
	Interrupt: pin C routed to IRQ 18
	Region 0: Memory at f7f05000 (64-bit, non-prefetchable) [size=256]
	Region 4: I/O ports at f040 [size=32]

05:00.0 0200: 10ec:8168 (rev 06)
	Subsystem: 1028:04b3
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 41
	Region 0: I/O ports at e000 [size=256]
	Region 2: Memory at f1104000 (64-bit, prefetchable) [size=4K]
	Region 4: Memory at f1100000 (64-bit, prefetchable) [size=16K]
	Capabilities: [40] Power Management version 3
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000fee0300c  Data: 41a1
	Capabilities: [70] Express (v2) Endpoint, MSI 01
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 4096 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
			ClockPM+ Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
	Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
		Vector table: BAR=4 offset=00000000
		PBA: BAR=4 offset=00000800
	Capabilities: [d0] Vital Product Data
		Unknown small resource type 00, will not decode more.
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
	Capabilities: [140 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed- WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
			Status:	NegoPending- InProgress-
	Capabilities: [160 v1] Device Serial Number 01-00-00-00-68-4c-e0-00
	Kernel driver in use: r8169

09:00.0 0280: 8086:008a (rev 34)
	Subsystem: 8086:5325
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 46
	Region 0: Memory at f7e00000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: [c8] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000fee0300c  Data: 4152
	Capabilities: [e0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 <32us
			ClockPM+ Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
	Capabilities: [140 v1] Device Serial Number 4c-80-93-ff-ff-15-e6-c7
	Kernel driver in use: iwlwifi

0b:00.0 0c03: 104c:8241 (rev 02) (prog-if 30 [XHCI])
	Subsystem: 1028:04b3
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at f7d00000 (64-bit, non-prefetchable) [size=64K]
	Region 2: Memory at f7d10000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: [40] Power Management version 3
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=100mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [48] MSI: Enable- Count=1/8 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v2) Endpoint, MSI 00
		DevCap:	MaxPayload 1024 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
			ClockPM+ Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
		LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
			 EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
	Capabilities: [c0] MSI-X: Enable+ Count=8 Masked-
		Vector table: BAR=2 offset=00000000
		PBA: BAR=2 offset=00001000
	Capabilities: [100 v2] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
		AERCap:	First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
	Capabilities: [150 v1] Device Serial Number 08-00-28-00-00-20-00-00
	Kernel driver in use: xhci_hcd

11:00.0 0180: 1095:3132 (rev 01)
	Subsystem: 1095:3132
	Physical Slot: 1
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 19
	Region 0: Memory at f6c84000 (64-bit, non-prefetchable) [size=128]
	Region 2: Memory at f6c80000 (64-bit, non-prefetchable) [size=16K]
	Region 4: I/O ports at c000 [size=128]
	Expansion ROM at f6c00000 [disabled] [size=512K]
	Capabilities: [54] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [5c] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v1) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 1024 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 4096 bytes
		DevSta:	CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		AERCap:	First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
	Kernel driver in use: sata_sil24


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications
  2013-03-29 16:05       ` Sarah Sharp
  2013-03-29 17:11         ` Martin Mokrejs
@ 2013-03-29 21:37         ` Rafael J. Wysocki
  1 sibling, 0 replies; 24+ messages in thread
From: Rafael J. Wysocki @ 2013-03-29 21:37 UTC (permalink / raw)
  To: Sarah Sharp
  Cc: Martin Mokrejs, Bjorn Helgaas, ACPI Devel Maling List, LKML,
	Linux PM list, Len Brown, Matthew Garrett, Accardi, Kristen C,
	Huang, Ying, linux-pci

On Friday, March 29, 2013 09:05:35 AM Sarah Sharp wrote:
> On Fri, Mar 29, 2013 at 04:05:54PM +0100, Martin Mokrejs wrote:
> > [   36.594171] xhci_hcd 0000:0b:00.0: xhci_suspend: stopping port polling.
> > [   36.594202] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
> > [   36.594247] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_suspend: 0
> > [   36.594349] xhci_hcd 0000:0b:00.0: PME# enabled
> > [   36.703695] r8169 0000:05:00.0 eth0: link down
> > [   37.098299] microcode: CPU0 updated to revision 0x28, date = 2012-04-24
> > [   37.098941] microcode: CPU1 updated to revision 0x28, date = 2012-04-24
> > [   37.098944] perf_event_intel: PEBS enabled due to microcode update
> > [   38.343029] r8169 0000:05:00.0 eth0: link up
> > [   39.094944] r8169 0000:05:00.0 eth0: link down
> > [   41.492768] r8169 0000:05:00.0 eth0: link up
> > [   62.782910] xhci_hcd 0000:0b:00.0: Poll event ring: 4294943584
> > [   62.782938] xhci_hcd 0000:0b:00.0: op reg status = 0xffffffff
> > [   62.782939] xhci_hcd 0000:0b:00.0: HW died, polling stopped.
> > [   88.754183] pcieport 0000:00:1c.0: PME# enabled
> > [   88.764182] xhci_hcd 0000:0b:00.0: PME# disabled
> > [   88.764192] xhci_hcd 0000:0b:00.0: enabling bus mastering
> > [   88.764206] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
> > [   88.764242] xhci_hcd 0000:0b:00.0: Port Status Change Event for port 2
> > [   88.764246] xhci_hcd 0000:0b:00.0: resume root hub
> > [   88.764259] xhci_hcd 0000:0b:00.0: handle_port_status: starting port polling.
> > [   88.764276] xhci_hcd 0000:0b:00.0: xhci_resume: starting port polling.
> > [   88.764281] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_resume: 0
> > 
> > 
> > What "HW died? Why 1c.0 is here? What is this device actually doing?
> 
> It's harmless.  The xHCI polling loop to debug the host registers and
> rings simply notices that the registers are reading as all ffs.  I
> believe that's normal when a PCI device is in D3.  I just haven't had
> time to make a patch to disable the polling loop when the host is suspended.
> 
> So, for now, ignore the "HW died, polling stopped." messages.
> 
> > Nevertheless, I went to check if if the USB3 socket dies after first unplug of device
> > or not anymore thanks to the patch being tested:
> > 
> > I plugged into the USB3.0 socket a mouse, it worked. Around its unplug I got:
> > 
> > [   94.954779] hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
> > [   94.954795] hub 3-0:1.0: hub_suspend
> > [   94.954802] usb usb3: bus auto-suspend, wakeup 1
> > [   94.954817] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
> > [   94.954835] xhci_hcd 0000:0b:00.0: xhci_suspend: stopping port polling.
> > [   94.954857] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
> > [   94.954898] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_suspend: 0
> > [   94.954983] xhci_hcd 0000:0b:00.0: PME# enabled
> > [  169.622513] hub 2-1:1.0: state 7 ports 8 chg 0000 evt 0004
> > [  169.623057] hub 2-1:1.0: port 2, status 0101, change 0001, 12 Mb/s
> > [  169.777012] hub 2-1:1.0: debounce: port 2: total 100ms stable 100ms status 0x101
> > [  169.856992] usb 2-1.2: new low-speed USB device number 4 using ehci-pci
> > 
> > and the port was dead, no matter what "lsusb -v or -vv" options I tried. At about
> > [  169.622513] I plugged the mouse into a USB2.0 socket (do not know if that is 1a.0 or 1d.0).
> 
> All right, I wonder if the USB core/xHCI driver is forgetting to clear a
> port status change bit after the device is unplugged.  That can cause
> the xHCI host to not give us a port status change event later (and thus
> no PME).  Looking at the logs later, it doesn't seem like we do this
> though.
> 
> > If I run lsusb -vv it does (with the problematic patch):
> > 
> > [ 1760.414086] pcieport 0000:00:1c.4: PME# disabled
> > [ 1760.434314] xhci_hcd 0000:0b:00.0: PME# disabled
> > [ 1760.434327] xhci_hcd 0000:0b:00.0: enabling bus mastering
> > [ 1760.434338] xhci_hcd 0000:0b:00.0: // Setting command ring address to 0xd6007001
> > [ 1760.434360] xhci_hcd 0000:0b:00.0: Port Status Change Event for port 2
> 
> Ok, so the xHCI driver *is* getting a port status change event, and thus
> must have gotten a PME.  So the PCI layer is doing its job.
> 
> > [ 1760.434363] xhci_hcd 0000:0b:00.0: resume root hub
> > [ 1760.434367] xhci_hcd 0000:0b:00.0: handle_port_status: starting port polling.
> > [ 1760.434378] xhci_hcd 0000:0b:00.0: xhci_resume: starting port polling.
> > [ 1760.434383] xhci_hcd 0000:0b:00.0: hcd_pci_runtime_resume: 0
> > [ 1760.434388] usb usb3: usb auto-resume
> > [ 1760.434407] hub 3-0:1.0: hub_resume
> > [ 1760.434439] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
> > [ 1760.434440] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
> > [ 1760.434464] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x202a0
> > [ 1760.434465] xhci_hcd 0000:0b:00.0: Get port status returned 0x10100
> > [ 1760.434492] xhci_hcd 0000:0b:00.0: clear port connect change, actual port 1 status  = 0x2a0
> 
> Odd.  The port status shows there's no device connected, but there was a
> connect change:
> 
> sarah@xanatos:~$ ./decode-port-status 0x202a0
> port status = 0x0202a0
>  bit  0     (CCS)          0x0, device not connected
>  bit  1     (PED)          0x0, port disabled
>  bit  3     (OCA)          0x0, no over-current condition
>  bit  4     (PR)           0x0, port not in reset
>  bits 8:5   (PLS)          0x5, link is in the RxDetect state
>  bit  9     (PP)           0x1, port power on
>  bits 13:10 (speed)        0x0, Undefined
>  bits 15:14 (indicators)   0x0, port indicators are off
>  bit  17    (CSC)          0x1, connect change
>  bit  18    (PEC)          0x0, no port enable/disable change
>  bit  19    (WRC)          0x0, no warm port reset change
>  bit  20    (OCC)          0x0, no over-current change
>  bit  21    (PRC)          0x0, no port reset change
>  bit  22    (PLC)          0x0, no port link change
>  bit  23    (CEC)          0x0, no port config error change
>  bit  25    (WCE)          0x0, wake on connect disabled
>  bit  26    (WDE)          0x0, wake on disconnect disabled
>  bit  27    (WOE)          0x0, wake on over-current enable disabled
>  bit  30    (DR)           0x0, device is permanently attached
> 
> RxDetect is the "I'm looking for a USB device" port state.
> 
> > [ 1760.434642] usb usb4: usb wakeup-resume
> > [ 1760.434646] usb usb4: usb auto-resume
> > [ 1760.434661] hub 4-0:1.0: hub_resume
> > [ 1760.434683] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
> > [ 1760.434684] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
> > [ 1760.434710] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
> > [ 1760.434711] xhci_hcd 0000:0b:00.0: Get port status returned 0x2a0
> > [ 1760.434727] hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0000
> > [ 1760.434757] xhci_hcd 0000:0b:00.0: set port remote wake mask, actual port 0 status  = 0xe0002a0
> > [ 1760.434784] xhci_hcd 0000:0b:00.0: set port remote wake mask, actual port 1 status  = 0xe0002a0
> > [ 1760.434791] hub 4-0:1.0: hub_suspend
> > [ 1760.434796] usb usb4: bus auto-suspend, wakeup 1
> > [ 1760.434807] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
> > [ 1760.553734] xhci_hcd 0000:0b:00.0: xhci_hub_status_data: stopping port polling.
> > [ 1760.553751] hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0000
> > [ 1760.574793] xhci_hcd 0000:0b:00.0: get port status, actual port 0 status  = 0x2a0
> > [ 1760.574794] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
> > [ 1760.575300] xhci_hcd 0000:0b:00.0: get port status, actual port 1 status  = 0x2a0
> > [ 1760.575301] xhci_hcd 0000:0b:00.0: Get port status returned 0x100
> 
> sarah@xanatos:~$ ./decode-port-status 0x2a0
> port status = 0x0002a0
>  bit  0     (CCS)          0x0, device not connected
>  bit  1     (PED)          0x0, port disabled
>  bit  3     (OCA)          0x0, no over-current condition
>  bit  4     (PR)           0x0, port not in reset
>  bits 8:5   (PLS)          0x5, link is in the RxDetect state
>  bit  9     (PP)           0x1, port power on
>  bits 13:10 (speed)        0x0, Undefined
>  bits 15:14 (indicators)   0x0, port indicators are off
>  bit  17    (CSC)          0x0, no connect change
>  bit  18    (PEC)          0x0, no port enable/disable change
>  bit  19    (WRC)          0x0, no warm port reset change
>  bit  20    (OCC)          0x0, no over-current change
>  bit  21    (PRC)          0x0, no port reset change
>  bit  22    (PLC)          0x0, no port link change
>  bit  23    (CEC)          0x0, no port config error change
>  bit  25    (WCE)          0x0, wake on connect disabled
>  bit  26    (WDE)          0x0, wake on disconnect disabled
>  bit  27    (WOE)          0x0, wake on over-current enable disabled
>  bit  30    (DR)           0x0, device is permanently attached
> 
> Nope, your host really isn't reporting there's a device connected
> *at all*.  That's just broken hardware, and there's really nothing
> software can do if the hardware isn't reporting connect events, even
> with polling.
> 
> It also doesn't sound like the other TI redriver bug.  That bug only
> effected USB 3.0 ports, and when lsusb was run, we would find the port
> in Compliance Mode.  This is the host simply not reporting the USB 2.0
> port connect at all.
> 
> Maybe if we completely disable PCI runtime PM for your host, we can work
> around this bug?

Well, that's what I've just asked Martin to try.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications
  2013-03-29 15:05     ` Martin Mokrejs
  2013-03-29 16:05       ` Sarah Sharp
@ 2013-03-29 21:34       ` Rafael J. Wysocki
  1 sibling, 0 replies; 24+ messages in thread
From: Rafael J. Wysocki @ 2013-03-29 21:34 UTC (permalink / raw)
  To: Martin Mokrejs
  Cc: Bjorn Helgaas, ACPI Devel Maling List, LKML, Linux PM list,
	Len Brown, Matthew Garrett, Sarah Sharp, Accardi, Kristen C,
	Huang, Ying, linux-pci

On Friday, March 29, 2013 04:05:54 PM Martin Mokrejs wrote:
> Hi,
>   I applied this patches over 3.8.3 hoping it will fix my issue under
> thread: "Re: 3.8.2: xhci port is dead until pcieport PME# goes to disabled"
> but unfortunately, it is even worse! Now, although lsusb -v nor lsusb -vv do
> wakeup the XHCI port but it falls asleep immediately, more quickly than I am
> able to plug a device into the socket. To get a device working in the USB3 socket
> I need to plug it in, run lsusb -vv and then it is recognized.
> 
> Without the patch, the 'lsusb -vv' woke up the port (PME# disabled happened
> on both 1c.4 and 0b:00.0) and I had unlimited time to find some USB device
> around and to plug it into the slot.

Well, using lsusb to work around problems in the PCI subsystem isn't even
*supposed* to work as far as I can tell.

First off, do you use laptop-mode (or something equivalent) to enable runtime
PM for all PCI devices in your system?  If you do, please test things without
it and see if they work then.

Second, do things work after you echo "on" to the xHCI controller's
/sys/devices/.../power/control file?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications
  2013-03-28 21:07   ` [Update][PATCH] " Rafael J. Wysocki
  2013-03-29 15:05     ` Martin Mokrejs
@ 2013-04-03 22:38     ` Bjorn Helgaas
  1 sibling, 0 replies; 24+ messages in thread
From: Bjorn Helgaas @ 2013-04-03 22:38 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: ACPI Devel Maling List, LKML, Linux PM list, Len Brown,
	Matthew Garrett, Sarah Sharp, Accardi, Kristen C, Huang, Ying,
	linux-pci@vger.kernel.org

On Thu, Mar 28, 2013 at 3:07 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Subject: PCI / ACPI: Always resume devices on ACPI wakeup notifications
>
> It turns out that the _Lxx control methods provided by some BIOSes
> clear the PME Status bit of PCI devices they handle, which means that
> pci_acpi_wake_dev() cannot really use that bit to check whether or
> not the device has signalled wakeup.
>
> One symptom of the problem is, for example, that when an affected PCI
> USB controller is runtime-suspended, then plugging in a new USB device
> into one of the controller's ports will not wake up the controller,
> which should happen.
>
> For this reason, make pci_acpi_wake_dev() always attempt to resume
> the device it is called for regardless of the device's PME Status bit
> value (that bit still has to be cleared if set at this point,
> though).
>
> Reported-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
> Cc: 3.7+ <stable@vger.kernel.org>
> ---
>
> The changelog in this version is slightly better than in the previous one, IMHO.

I applied this to for-linus for v3.9.  Thanks!

> ---
>  drivers/pci/pci-acpi.c |   15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> Index: linux-pm/drivers/pci/pci-acpi.c
> ===================================================================
> --- linux-pm.orig/drivers/pci/pci-acpi.c
> +++ linux-pm/drivers/pci/pci-acpi.c
> @@ -53,14 +53,15 @@ static void pci_acpi_wake_dev(acpi_handl
>                 return;
>         }
>
> -       if (!pci_dev->pm_cap || !pci_dev->pme_support
> -            || pci_check_pme_status(pci_dev)) {
> -               if (pci_dev->pme_poll)
> -                       pci_dev->pme_poll = false;
> +       /* Clear PME Status if set. */
> +       if (pci_dev->pme_support)
> +               pci_check_pme_status(pci_dev);
>
> -               pci_wakeup_event(pci_dev);
> -               pm_runtime_resume(&pci_dev->dev);
> -       }
> +       if (pci_dev->pme_poll)
> +               pci_dev->pme_poll = false;
> +
> +       pci_wakeup_event(pci_dev);
> +       pm_runtime_resume(&pci_dev->dev);
>
>         if (pci_dev->subordinate)
>                 pci_pme_wakeup_bus(pci_dev->subordinate);
>

^ permalink raw reply	[flat|nested] 24+ messages in thread

[parent not found: <51548C9E.9090703@fold.natur.cuni.cz>]

[parent not found: <2990024.LMTIBUbM3d@vostro.rjw.lan>]

* [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports
       [not found]   ` <2990024.LMTIBUbM3d@vostro.rjw.lan>
@ 2013-03-30 22:38     ` Rafael J. Wysocki
  2013-04-01 17:34       ` Bjorn Helgaas
  2013-04-03 22:34       ` Bjorn Helgaas
  0 siblings, 2 replies; 24+ messages in thread
From: Rafael J. Wysocki @ 2013-03-30 22:38 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Martin Mokrejs, ACPI Devel Maling List, Len Brown,
	Matthew Garrett, Sarah Sharp, LKML, linux-pci

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The runtime PM of PCIe ports turns out to be quite fragile, as in
some cases things work while in some other cases they don't and we
don't seem to have a good way to determine whether or not they are
going to work in advance.

For this reason, avoid enabling runtime PM for PCIe ports by
keeping their runtime PM reference counters always above 0 for the
time being.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

This version also removes the no longer necessary (and empty anyway)
port_runtime_pm_black_list[] table.

Thanks,
Rafael

---
 drivers/pci/pcie/portdrv_pci.c |   13 -------------
 1 file changed, 13 deletions(-)

Index: linux-pm/drivers/pci/pcie/portdrv_pci.c
===================================================================
--- linux-pm.orig/drivers/pci/pcie/portdrv_pci.c
+++ linux-pm/drivers/pci/pcie/portdrv_pci.c
@@ -185,14 +185,6 @@ static const struct dev_pm_ops pcie_port
 #endif /* !PM */
 
 /*
- * PCIe port runtime suspend is broken for some chipsets, so use a
- * black list to disable runtime PM for these chipsets.
- */
-static const struct pci_device_id port_runtime_pm_black_list[] = {
-	{ /* end: all zeroes */ }
-};
-
-/*
  * pcie_portdrv_probe - Probe PCI-Express port devices
  * @dev: PCI-Express port device being probed
  *
@@ -225,16 +217,11 @@ static int pcie_portdrv_probe(struct pci
 	 * it by default.
 	 */
 	dev->d3cold_allowed = false;
-	if (!pci_match_id(port_runtime_pm_black_list, dev))
-		pm_runtime_put_noidle(&dev->dev);
-
 	return 0;
 }
 
 static void pcie_portdrv_remove(struct pci_dev *dev)
 {
-	if (!pci_match_id(port_runtime_pm_black_list, dev))
-		pm_runtime_get_noresume(&dev->dev);
 	pcie_port_device_remove(dev);
 	pci_disable_device(dev);
 }


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports
  2013-03-30 22:38     ` [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports Rafael J. Wysocki
@ 2013-04-01 17:34       ` Bjorn Helgaas
  2013-04-01 20:51         ` Rafael J. Wysocki
  2013-04-03 22:34       ` Bjorn Helgaas
  1 sibling, 1 reply; 24+ messages in thread
From: Bjorn Helgaas @ 2013-04-01 17:34 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Martin Mokrejs, ACPI Devel Maling List, Len Brown,
	Matthew Garrett, Sarah Sharp, LKML, linux-pci@vger.kernel.org,
	Zheng Yan

[+cc Zheng, who added this with 71a83bd727]

On Sat, Mar 30, 2013 at 4:38 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> The runtime PM of PCIe ports turns out to be quite fragile, as in
> some cases things work while in some other cases they don't and we
> don't seem to have a good way to determine whether or not they are
> going to work in advance.

Do you have any references to problems encountered when enabling
runtime PM for PCIe ports?  That information will be useful to anybody
who wants to take another crack at getting this working.

> For this reason, avoid enabling runtime PM for PCIe ports by
> keeping their runtime PM reference counters always above 0 for the
> time being.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>
> This version also removes the no longer necessary (and empty anyway)
> port_runtime_pm_black_list[] table.
>
> Thanks,
> Rafael
>
> ---
>  drivers/pci/pcie/portdrv_pci.c |   13 -------------
>  1 file changed, 13 deletions(-)
>
> Index: linux-pm/drivers/pci/pcie/portdrv_pci.c
> ===================================================================
> --- linux-pm.orig/drivers/pci/pcie/portdrv_pci.c
> +++ linux-pm/drivers/pci/pcie/portdrv_pci.c
> @@ -185,14 +185,6 @@ static const struct dev_pm_ops pcie_port
>  #endif /* !PM */
>
>  /*
> - * PCIe port runtime suspend is broken for some chipsets, so use a
> - * black list to disable runtime PM for these chipsets.
> - */
> -static const struct pci_device_id port_runtime_pm_black_list[] = {
> -       { /* end: all zeroes */ }
> -};
> -
> -/*
>   * pcie_portdrv_probe - Probe PCI-Express port devices
>   * @dev: PCI-Express port device being probed
>   *
> @@ -225,16 +217,11 @@ static int pcie_portdrv_probe(struct pci
>          * it by default.
>          */
>         dev->d3cold_allowed = false;
> -       if (!pci_match_id(port_runtime_pm_black_list, dev))
> -               pm_runtime_put_noidle(&dev->dev);
> -
>         return 0;
>  }
>
>  static void pcie_portdrv_remove(struct pci_dev *dev)
>  {
> -       if (!pci_match_id(port_runtime_pm_black_list, dev))
> -               pm_runtime_get_noresume(&dev->dev);
>         pcie_port_device_remove(dev);
>         pci_disable_device(dev);
>  }
>

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports
  2013-04-01 17:34       ` Bjorn Helgaas
@ 2013-04-01 20:51         ` Rafael J. Wysocki
  2013-04-01 20:53           ` Bjorn Helgaas
  2013-04-02  5:28           ` huang ying
  0 siblings, 2 replies; 24+ messages in thread
From: Rafael J. Wysocki @ 2013-04-01 20:51 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Martin Mokrejs, ACPI Devel Maling List, Len Brown,
	Matthew Garrett, Sarah Sharp, LKML, linux-pci@vger.kernel.org,
	Zheng Yan

On Monday, April 01, 2013 11:34:46 AM Bjorn Helgaas wrote:
> [+cc Zheng, who added this with 71a83bd727]
> 
> On Sat, Mar 30, 2013 at 4:38 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > The runtime PM of PCIe ports turns out to be quite fragile, as in
> > some cases things work while in some other cases they don't and we
> > don't seem to have a good way to determine whether or not they are
> > going to work in advance.
> 
> Do you have any references to problems encountered when enabling
> runtime PM for PCIe ports?  That information will be useful to anybody
> who wants to take another crack at getting this working.

Well, bug 53811 is one example and problems recently reported by
Martin are another.  Do you want me to dig deeper?

Rafael


> > For this reason, avoid enabling runtime PM for PCIe ports by
> > keeping their runtime PM reference counters always above 0 for the
> > time being.
> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > ---
> >
> > This version also removes the no longer necessary (and empty anyway)
> > port_runtime_pm_black_list[] table.
> >
> > Thanks,
> > Rafael
> >
> > ---
> >  drivers/pci/pcie/portdrv_pci.c |   13 -------------
> >  1 file changed, 13 deletions(-)
> >
> > Index: linux-pm/drivers/pci/pcie/portdrv_pci.c
> > ===================================================================
> > --- linux-pm.orig/drivers/pci/pcie/portdrv_pci.c
> > +++ linux-pm/drivers/pci/pcie/portdrv_pci.c
> > @@ -185,14 +185,6 @@ static const struct dev_pm_ops pcie_port
> >  #endif /* !PM */
> >
> >  /*
> > - * PCIe port runtime suspend is broken for some chipsets, so use a
> > - * black list to disable runtime PM for these chipsets.
> > - */
> > -static const struct pci_device_id port_runtime_pm_black_list[] = {
> > -       { /* end: all zeroes */ }
> > -};
> > -
> > -/*
> >   * pcie_portdrv_probe - Probe PCI-Express port devices
> >   * @dev: PCI-Express port device being probed
> >   *
> > @@ -225,16 +217,11 @@ static int pcie_portdrv_probe(struct pci
> >          * it by default.
> >          */
> >         dev->d3cold_allowed = false;
> > -       if (!pci_match_id(port_runtime_pm_black_list, dev))
> > -               pm_runtime_put_noidle(&dev->dev);
> > -
> >         return 0;
> >  }
> >
> >  static void pcie_portdrv_remove(struct pci_dev *dev)
> >  {
> > -       if (!pci_match_id(port_runtime_pm_black_list, dev))
> > -               pm_runtime_get_noresume(&dev->dev);
> >         pcie_port_device_remove(dev);
> >         pci_disable_device(dev);
> >  }
> >
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports
  2013-04-01 20:51         ` Rafael J. Wysocki
@ 2013-04-01 20:53           ` Bjorn Helgaas
  2013-04-01 21:24             ` Rafael J. Wysocki
                               ` (2 more replies)
  2013-04-02  5:28           ` huang ying
  1 sibling, 3 replies; 24+ messages in thread
From: Bjorn Helgaas @ 2013-04-01 20:53 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Martin Mokrejs, ACPI Devel Maling List, Len Brown,
	Matthew Garrett, Sarah Sharp, LKML, linux-pci@vger.kernel.org,
	Zheng Yan

On Mon, Apr 1, 2013 at 2:51 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Monday, April 01, 2013 11:34:46 AM Bjorn Helgaas wrote:
>> [+cc Zheng, who added this with 71a83bd727]
>>
>> On Sat, Mar 30, 2013 at 4:38 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> >
>> > The runtime PM of PCIe ports turns out to be quite fragile, as in
>> > some cases things work while in some other cases they don't and we
>> > don't seem to have a good way to determine whether or not they are
>> > going to work in advance.
>>
>> Do you have any references to problems encountered when enabling
>> runtime PM for PCIe ports?  That information will be useful to anybody
>> who wants to take another crack at getting this working.
>
> Well, bug 53811 is one example and problems recently reported by
> Martin are another.  Do you want me to dig deeper?

OK, I got this one:

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

Martin has reported a lot of problems lately, and I don't know which
are related to runtime PM for PCIe ports.  I was hoping for a couple
URLs to put in the changelog so that when somebody gets the itch to
make this work, they have some useful info to start from.  If you
point me at a specific message, I'll dig up an archive URL for it.

Otherwise, I'm afraid we'll just oscillate between "enable PM, find
bug, disable PM, enable PM, find same bug, disable PM, etc..."

Bjorn

>> > For this reason, avoid enabling runtime PM for PCIe ports by
>> > keeping their runtime PM reference counters always above 0 for the
>> > time being.
>> >
>> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> > ---
>> >
>> > This version also removes the no longer necessary (and empty anyway)
>> > port_runtime_pm_black_list[] table.
>> >
>> > Thanks,
>> > Rafael
>> >
>> > ---
>> >  drivers/pci/pcie/portdrv_pci.c |   13 -------------
>> >  1 file changed, 13 deletions(-)
>> >
>> > Index: linux-pm/drivers/pci/pcie/portdrv_pci.c
>> > ===================================================================
>> > --- linux-pm.orig/drivers/pci/pcie/portdrv_pci.c
>> > +++ linux-pm/drivers/pci/pcie/portdrv_pci.c
>> > @@ -185,14 +185,6 @@ static const struct dev_pm_ops pcie_port
>> >  #endif /* !PM */
>> >
>> >  /*
>> > - * PCIe port runtime suspend is broken for some chipsets, so use a
>> > - * black list to disable runtime PM for these chipsets.
>> > - */
>> > -static const struct pci_device_id port_runtime_pm_black_list[] = {
>> > -       { /* end: all zeroes */ }
>> > -};
>> > -
>> > -/*
>> >   * pcie_portdrv_probe - Probe PCI-Express port devices
>> >   * @dev: PCI-Express port device being probed
>> >   *
>> > @@ -225,16 +217,11 @@ static int pcie_portdrv_probe(struct pci
>> >          * it by default.
>> >          */
>> >         dev->d3cold_allowed = false;
>> > -       if (!pci_match_id(port_runtime_pm_black_list, dev))
>> > -               pm_runtime_put_noidle(&dev->dev);
>> > -
>> >         return 0;
>> >  }
>> >
>> >  static void pcie_portdrv_remove(struct pci_dev *dev)
>> >  {
>> > -       if (!pci_match_id(port_runtime_pm_black_list, dev))
>> > -               pm_runtime_get_noresume(&dev->dev);
>> >         pcie_port_device_remove(dev);
>> >         pci_disable_device(dev);
>> >  }
>> >
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports
  2013-04-01 20:53           ` Bjorn Helgaas
@ 2013-04-01 21:24             ` Rafael J. Wysocki
  2013-04-01 23:20               ` Rafael J. Wysocki
  2013-04-01 21:48             ` Martin Mokrejs
  2013-04-02  5:34             ` huang ying
  2 siblings, 1 reply; 24+ messages in thread
From: Rafael J. Wysocki @ 2013-04-01 21:24 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Martin Mokrejs, ACPI Devel Maling List, Len Brown,
	Matthew Garrett, Sarah Sharp, LKML, linux-pci@vger.kernel.org,
	Zheng Yan

On Monday, April 01, 2013 02:53:12 PM Bjorn Helgaas wrote:
> On Mon, Apr 1, 2013 at 2:51 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Monday, April 01, 2013 11:34:46 AM Bjorn Helgaas wrote:
> >> [+cc Zheng, who added this with 71a83bd727]
> >>
> >> On Sat, Mar 30, 2013 at 4:38 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >> >
> >> > The runtime PM of PCIe ports turns out to be quite fragile, as in
> >> > some cases things work while in some other cases they don't and we
> >> > don't seem to have a good way to determine whether or not they are
> >> > going to work in advance.
> >>
> >> Do you have any references to problems encountered when enabling
> >> runtime PM for PCIe ports?  That information will be useful to anybody
> >> who wants to take another crack at getting this working.
> >
> > Well, bug 53811 is one example and problems recently reported by
> > Martin are another.  Do you want me to dig deeper?
> 
> OK, I got this one:
> 
>   https://bugzilla.kernel.org/show_bug.cgi?id=53811
> 
> Martin has reported a lot of problems lately, and I don't know which
> are related to runtime PM for PCIe ports.  I was hoping for a couple
> URLs to put in the changelog so that when somebody gets the itch to
> make this work, they have some useful info to start from.  If you
> point me at a specific message, I'll dig up an archive URL for it.

This is the message in which Martin confirmed that the previous version of
the $subject patch made insert/removal of devices into xHCI ports on his
system work again.

> Otherwise, I'm afraid we'll just oscillate between "enable PM, find
> bug, disable PM, enable PM, find same bug, disable PM, etc..."

That's a valid concern, but I think we have an idea about what kind of problems
the runtime PM of PCIe ports may cause to happen (generally, PME and hotplug
notifications may not work as expected).

Thanks,
Rafael


> >> > For this reason, avoid enabling runtime PM for PCIe ports by
> >> > keeping their runtime PM reference counters always above 0 for the
> >> > time being.
> >> >
> >> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >> > ---
> >> >
> >> > This version also removes the no longer necessary (and empty anyway)
> >> > port_runtime_pm_black_list[] table.
> >> >
> >> > Thanks,
> >> > Rafael
> >> >
> >> > ---
> >> >  drivers/pci/pcie/portdrv_pci.c |   13 -------------
> >> >  1 file changed, 13 deletions(-)
> >> >
> >> > Index: linux-pm/drivers/pci/pcie/portdrv_pci.c
> >> > ===================================================================
> >> > --- linux-pm.orig/drivers/pci/pcie/portdrv_pci.c
> >> > +++ linux-pm/drivers/pci/pcie/portdrv_pci.c
> >> > @@ -185,14 +185,6 @@ static const struct dev_pm_ops pcie_port
> >> >  #endif /* !PM */
> >> >
> >> >  /*
> >> > - * PCIe port runtime suspend is broken for some chipsets, so use a
> >> > - * black list to disable runtime PM for these chipsets.
> >> > - */
> >> > -static const struct pci_device_id port_runtime_pm_black_list[] = {
> >> > -       { /* end: all zeroes */ }
> >> > -};
> >> > -
> >> > -/*
> >> >   * pcie_portdrv_probe - Probe PCI-Express port devices
> >> >   * @dev: PCI-Express port device being probed
> >> >   *
> >> > @@ -225,16 +217,11 @@ static int pcie_portdrv_probe(struct pci
> >> >          * it by default.
> >> >          */
> >> >         dev->d3cold_allowed = false;
> >> > -       if (!pci_match_id(port_runtime_pm_black_list, dev))
> >> > -               pm_runtime_put_noidle(&dev->dev);
> >> > -
> >> >         return 0;
> >> >  }
> >> >
> >> >  static void pcie_portdrv_remove(struct pci_dev *dev)
> >> >  {
> >> > -       if (!pci_match_id(port_runtime_pm_black_list, dev))
> >> > -               pm_runtime_get_noresume(&dev->dev);
> >> >         pcie_port_device_remove(dev);
> >> >         pci_disable_device(dev);
> >> >  }
> >> >
> > --
> > I speak only for myself.
> > Rafael J. Wysocki, Intel Open Source Technology Center.
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports
  2013-04-01 21:24             ` Rafael J. Wysocki
@ 2013-04-01 23:20               ` Rafael J. Wysocki
  0 siblings, 0 replies; 24+ messages in thread
From: Rafael J. Wysocki @ 2013-04-01 23:20 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Martin Mokrejs, ACPI Devel Maling List, Len Brown,
	Matthew Garrett, Sarah Sharp, LKML, linux-pci@vger.kernel.org,
	Zheng Yan

On Monday, April 01, 2013 11:24:37 PM Rafael J. Wysocki wrote:
> On Monday, April 01, 2013 02:53:12 PM Bjorn Helgaas wrote:
> > On Mon, Apr 1, 2013 at 2:51 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > > On Monday, April 01, 2013 11:34:46 AM Bjorn Helgaas wrote:
> > >> [+cc Zheng, who added this with 71a83bd727]
> > >>
> > >> On Sat, Mar 30, 2013 at 4:38 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > >> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >> >
> > >> > The runtime PM of PCIe ports turns out to be quite fragile, as in
> > >> > some cases things work while in some other cases they don't and we
> > >> > don't seem to have a good way to determine whether or not they are
> > >> > going to work in advance.
> > >>
> > >> Do you have any references to problems encountered when enabling
> > >> runtime PM for PCIe ports?  That information will be useful to anybody
> > >> who wants to take another crack at getting this working.
> > >
> > > Well, bug 53811 is one example and problems recently reported by
> > > Martin are another.  Do you want me to dig deeper?
> > 
> > OK, I got this one:
> > 
> >   https://bugzilla.kernel.org/show_bug.cgi?id=53811
> > 
> > Martin has reported a lot of problems lately, and I don't know which
> > are related to runtime PM for PCIe ports.  I was hoping for a couple
> > URLs to put in the changelog so that when somebody gets the itch to
> > make this work, they have some useful info to start from.  If you
> > point me at a specific message, I'll dig up an archive URL for it.
> 
> This is the message in which Martin confirmed that the previous version of
> the $subject patch made insert/removal of devices into xHCI ports on his
> system work again.
> 
> > Otherwise, I'm afraid we'll just oscillate between "enable PM, find
> > bug, disable PM, enable PM, find same bug, disable PM, etc..."
> 
> That's a valid concern, but I think we have an idea about what kind of problems
> the runtime PM of PCIe ports may cause to happen (generally, PME and hotplug
> notifications may not work as expected).

I was thinking about this one in particular:

http://marc.info/?l=linux-acpi&m=136460903910718&w=2

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports
  2013-04-01 20:53           ` Bjorn Helgaas
  2013-04-01 21:24             ` Rafael J. Wysocki
@ 2013-04-01 21:48             ` Martin Mokrejs
  2013-04-02  5:34             ` huang ying
  2 siblings, 0 replies; 24+ messages in thread
From: Martin Mokrejs @ 2013-04-01 21:48 UTC (permalink / raw)
  To: Bjorn Helgaas, Rafael J. Wysocki
  Cc: ACPI Devel Maling List, Len Brown, Matthew Garrett, Sarah Sharp,
	LKML, linux-pci@vger.kernel.org, Zheng Yan

Bjorn Helgaas wrote:
> On Mon, Apr 1, 2013 at 2:51 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> On Monday, April 01, 2013 11:34:46 AM Bjorn Helgaas wrote:
>>> [+cc Zheng, who added this with 71a83bd727]
>>>
>>> On Sat, Mar 30, 2013 at 4:38 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>>
>>>> The runtime PM of PCIe ports turns out to be quite fragile, as in
>>>> some cases things work while in some other cases they don't and we
>>>> don't seem to have a good way to determine whether or not they are
>>>> going to work in advance.
>>>
>>> Do you have any references to problems encountered when enabling
>>> runtime PM for PCIe ports?  That information will be useful to anybody
>>> who wants to take another crack at getting this working.
>>
>> Well, bug 53811 is one example and problems recently reported by
>> Martin are another.  Do you want me to dig deeper?
> 
> OK, I got this one:
> 
>   https://bugzilla.kernel.org/show_bug.cgi?id=53811
> 
> Martin has reported a lot of problems lately, and I don't know which
> are related to runtime PM for PCIe ports.  I was hoping for a couple
> URLs to put in the changelog so that when somebody gets the itch to
> make this work, they have some useful info to start from.  If you
> point me at a specific message, I'll dig up an archive URL for it.

In the thread

Re: 3.8.2: xhci port is dead until pcieport PME# goes to disabled
http://marc.info/?t=136328222600002&r=1&w=2

I reported that if an upstream express root port 1c.4 of the xHCI controller
at 0b:00 is suspended the USB3 socket on the laptop appears dead.
Initially I found that 'lsusb -v' rescues the dead socket and is accompanied
by these in logs:

[ 1445.597641] pcieport 0000:00:1c.4: PME# disabled
[ 1445.617667] xhci_hcd 0000:0b:00.0: PME# disabled

Ying Huang then realized elsewhere I am running laptop-mode-tools although
in their config file I set that they should NOT be run when on AC power.
Looks they do enable 'auto' power mode as seen in
/sys/bus/pci/devices/*/power/control files already upon bootup.
BTW, even worse, if I do /etc/init.d/laptop-mode-tools stop
they restore to some initial values. :(( So, if I meanwhile forced
'on' for some device they will return me back to 'auto' and the device
will immediately do suspend. ;-)

Provided I uninstalled the laptop-mode-tools and made sure all control
files say 'on' (and hence runtime_status files say 'active') then
my problem is with a dead xHCI port 'obeyed'.

Myself it weird that suspend of the port happens only upon USB device
unplug. The port does not suspend by itself if unused.

What is not clear to me how kernel is going to handle laptop-mode-tools
which enabled powersaving on the 1c.4. In my naive, user view kernel does
not realize and *check* that no user tool or a desperate user tried to
suspend an upstream port while there is something bound to it and it
does not apply a check for cascaded devices (1c.4 > 0b:00 and
1c.7 -> 11:00 in my case).

I am writing this without a reference but modprobe of a driver can overcome
suspended root port. I am in this particular case meaning my 1c.7 port
and its downstream 11:00 express card device. From the top of my head
I am not sure if modprobe overcame both 1c.7 and 11:00 being initially
suspended. I could dig it out from the

Re: 3.9-rc1: pciehp and eSATA card SiI 3132, no XHCI
http://marc.info/?t=136305008800001&r=1&w=2

thread if you want. Or it might be easier for you to test it yourself.

So, for me the issue is not fixed but if you decide to disable runtime
power saving for devices under pcieport I don't mind. Their mishandling
definitely causes my acpiphp hotplug issues under 3.7-3.8 kernels
(3.9-rc not tested) whereas these PM issues do not answer why pciehp
is broken on 3.7-3.9-rc1.

Anyway, this patch maybe only good because I would like to use the
laptop-mode-tools and they for sure will put one of the devices into 'auto'
and it will likely fall into suspend.
Martin

> 
> Otherwise, I'm afraid we'll just oscillate between "enable PM, find
> bug, disable PM, enable PM, find same bug, disable PM, etc..."
> 
> Bjorn
> 
>>>> For this reason, avoid enabling runtime PM for PCIe ports by
>>>> keeping their runtime PM reference counters always above 0 for the
>>>> time being.
>>>>
>>>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>>> ---
>>>>
>>>> This version also removes the no longer necessary (and empty anyway)
>>>> port_runtime_pm_black_list[] table.
>>>>
>>>> Thanks,
>>>> Rafael
>>>>
>>>> ---
>>>>  drivers/pci/pcie/portdrv_pci.c |   13 -------------
>>>>  1 file changed, 13 deletions(-)
>>>>
>>>> Index: linux-pm/drivers/pci/pcie/portdrv_pci.c
>>>> ===================================================================
>>>> --- linux-pm.orig/drivers/pci/pcie/portdrv_pci.c
>>>> +++ linux-pm/drivers/pci/pcie/portdrv_pci.c
>>>> @@ -185,14 +185,6 @@ static const struct dev_pm_ops pcie_port
>>>>  #endif /* !PM */
>>>>
>>>>  /*
>>>> - * PCIe port runtime suspend is broken for some chipsets, so use a
>>>> - * black list to disable runtime PM for these chipsets.
>>>> - */
>>>> -static const struct pci_device_id port_runtime_pm_black_list[] = {
>>>> -       { /* end: all zeroes */ }
>>>> -};
>>>> -
>>>> -/*
>>>>   * pcie_portdrv_probe - Probe PCI-Express port devices
>>>>   * @dev: PCI-Express port device being probed
>>>>   *
>>>> @@ -225,16 +217,11 @@ static int pcie_portdrv_probe(struct pci
>>>>          * it by default.
>>>>          */
>>>>         dev->d3cold_allowed = false;
>>>> -       if (!pci_match_id(port_runtime_pm_black_list, dev))
>>>> -               pm_runtime_put_noidle(&dev->dev);
>>>> -
>>>>         return 0;
>>>>  }
>>>>
>>>>  static void pcie_portdrv_remove(struct pci_dev *dev)
>>>>  {
>>>> -       if (!pci_match_id(port_runtime_pm_black_list, dev))
>>>> -               pm_runtime_get_noresume(&dev->dev);
>>>>         pcie_port_device_remove(dev);
>>>>         pci_disable_device(dev);
>>>>  }
>>>>
>> --
>> I speak only for myself.
>> Rafael J. Wysocki, Intel Open Source Technology Center.
> 
> 

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports
  2013-04-01 20:53           ` Bjorn Helgaas
  2013-04-01 21:24             ` Rafael J. Wysocki
  2013-04-01 21:48             ` Martin Mokrejs
@ 2013-04-02  5:34             ` huang ying
  2 siblings, 0 replies; 24+ messages in thread
From: huang ying @ 2013-04-02  5:34 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Rafael J. Wysocki, Martin Mokrejs, ACPI Devel Maling List,
	Len Brown, Matthew Garrett, Sarah Sharp, LKML,
	linux-pci@vger.kernel.org, Zheng Yan, Huang Ying

Hi, Bjorn,

On Tue, Apr 2, 2013 at 4:53 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Mon, Apr 1, 2013 at 2:51 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> On Monday, April 01, 2013 11:34:46 AM Bjorn Helgaas wrote:
>>> [+cc Zheng, who added this with 71a83bd727]
>>>
>>> On Sat, Mar 30, 2013 at 4:38 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>> >
>>> > The runtime PM of PCIe ports turns out to be quite fragile, as in
>>> > some cases things work while in some other cases they don't and we
>>> > don't seem to have a good way to determine whether or not they are
>>> > going to work in advance.
>>>
>>> Do you have any references to problems encountered when enabling
>>> runtime PM for PCIe ports?  That information will be useful to anybody
>>> who wants to take another crack at getting this working.
>>
>> Well, bug 53811 is one example and problems recently reported by
>> Martin are another.  Do you want me to dig deeper?
>
> OK, I got this one:
>
>   https://bugzilla.kernel.org/show_bug.cgi?id=53811
>
> Martin has reported a lot of problems lately, and I don't know which
> are related to runtime PM for PCIe ports.  I was hoping for a couple
> URLs to put in the changelog so that when somebody gets the itch to
> make this work, they have some useful info to start from.  If you
> point me at a specific message, I'll dig up an archive URL for it.
>
> Otherwise, I'm afraid we'll just oscillate between "enable PM, find
> bug, disable PM, enable PM, find same bug, disable PM, etc..."

Sorry for late!  I am trying to fix a way to fix 53811 and Martin's
bug without disable PM for port totally.

Best Regards,
Huang Ying

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports
  2013-04-01 20:51         ` Rafael J. Wysocki
  2013-04-01 20:53           ` Bjorn Helgaas
@ 2013-04-02  5:28           ` huang ying
  2013-04-02  5:31             ` huang ying
  1 sibling, 1 reply; 24+ messages in thread
From: huang ying @ 2013-04-02  5:28 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Bjorn Helgaas, Martin Mokrejs, ACPI Devel Maling List, Len Brown,
	Matthew Garrett, Sarah Sharp, LKML, linux-pci@vger.kernel.org,
	Zheng Yan

On Tue, Apr 2, 2013 at 4:51 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> On Monday, April 01, 2013 11:34:46 AM Bjorn Helgaas wrote:
> > [+cc Zheng, who added this with 71a83bd727]
> >
> > On Sat, Mar 30, 2013 at 4:38 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >
> > > The runtime PM of PCIe ports turns out to be quite fragile, as in
> > > some cases things work while in some other cases they don't and we
> > > don't seem to have a good way to determine whether or not they are
> > > going to work in advance.
> >
> > Do you have any references to problems encountered when enabling
> > runtime PM for PCIe ports?  That information will be useful to anybody
> > who wants to take another crack at getting this working.
>
> Well, bug 53811 is one example and problems recently reported by
> Martin are another.  Do you want me to dig deeper?

For bug 53811, I have a debug patch posted in bugzilla to disable
runtime PM for PCIe port with hotplug capability.  It appears that
patch resolved the issue for the reporter.  Do think that patch can
solve the hotplug issue.

Best Regards,
Huang Ying

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports
  2013-04-02  5:28           ` huang ying
@ 2013-04-02  5:31             ` huang ying
  0 siblings, 0 replies; 24+ messages in thread
From: huang ying @ 2013-04-02  5:31 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Bjorn Helgaas, Martin Mokrejs, ACPI Devel Maling List, Len Brown,
	Matthew Garrett, Sarah Sharp, LKML, linux-pci@vger.kernel.org,
	Zheng Yan, Huang Ying

On Tue, Apr 2, 2013 at 1:28 PM, huang ying <huang.ying.caritas@gmail.com> wrote:
> On Tue, Apr 2, 2013 at 4:51 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>
>> On Monday, April 01, 2013 11:34:46 AM Bjorn Helgaas wrote:
>> > [+cc Zheng, who added this with 71a83bd727]
>> >
>> > On Sat, Mar 30, 2013 at 4:38 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> > >
>> > > The runtime PM of PCIe ports turns out to be quite fragile, as in
>> > > some cases things work while in some other cases they don't and we
>> > > don't seem to have a good way to determine whether or not they are
>> > > going to work in advance.
>> >
>> > Do you have any references to problems encountered when enabling
>> > runtime PM for PCIe ports?  That information will be useful to anybody
>> > who wants to take another crack at getting this working.
>>
>> Well, bug 53811 is one example and problems recently reported by
>> Martin are another.  Do you want me to dig deeper?
>
> For bug 53811, I have a debug patch posted in bugzilla to disable
> runtime PM for PCIe port with hotplug capability.  It appears that
> patch resolved the issue for the reporter.  Do think that patch can
> solve the hotplug issue.

For Martin's hotplug issue, it appears that a similar patch I sent to
him resolve his hotplug issue too.  For Martin's "XHCI dead port"
issue, that is, PME issue.  I just sent him another debug patch to
try.  Sorry for late!

Best Regards,
Huang Ying

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports
  2013-03-30 22:38     ` [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports Rafael J. Wysocki
  2013-04-01 17:34       ` Bjorn Helgaas
@ 2013-04-03 22:34       ` Bjorn Helgaas
  1 sibling, 0 replies; 24+ messages in thread
From: Bjorn Helgaas @ 2013-04-03 22:34 UTC (permalink / raw)
  To: Rafael J. Wysocki, Zheng Yan
  Cc: Martin Mokrejs, ACPI Devel Maling List, Len Brown,
	Matthew Garrett, Sarah Sharp, LKML, linux-pci@vger.kernel.org

On Sat, Mar 30, 2013 at 4:38 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> The runtime PM of PCIe ports turns out to be quite fragile, as in
> some cases things work while in some other cases they don't and we
> don't seem to have a good way to determine whether or not they are
> going to work in advance.
>
> For this reason, avoid enabling runtime PM for PCIe ports by
> keeping their runtime PM reference counters always above 0 for the
> time being.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>
> This version also removes the no longer necessary (and empty anyway)
> port_runtime_pm_black_list[] table.

I applied this to for-linus for v3.9, and added a stable tag for v3.6+.  Thanks!

> ---
>  drivers/pci/pcie/portdrv_pci.c |   13 -------------
>  1 file changed, 13 deletions(-)
>
> Index: linux-pm/drivers/pci/pcie/portdrv_pci.c
> ===================================================================
> --- linux-pm.orig/drivers/pci/pcie/portdrv_pci.c
> +++ linux-pm/drivers/pci/pcie/portdrv_pci.c
> @@ -185,14 +185,6 @@ static const struct dev_pm_ops pcie_port
>  #endif /* !PM */
>
>  /*
> - * PCIe port runtime suspend is broken for some chipsets, so use a
> - * black list to disable runtime PM for these chipsets.
> - */
> -static const struct pci_device_id port_runtime_pm_black_list[] = {
> -       { /* end: all zeroes */ }
> -};
> -
> -/*
>   * pcie_portdrv_probe - Probe PCI-Express port devices
>   * @dev: PCI-Express port device being probed
>   *
> @@ -225,16 +217,11 @@ static int pcie_portdrv_probe(struct pci
>          * it by default.
>          */
>         dev->d3cold_allowed = false;
> -       if (!pci_match_id(port_runtime_pm_black_list, dev))
> -               pm_runtime_put_noidle(&dev->dev);
> -
>         return 0;
>  }
>
>  static void pcie_portdrv_remove(struct pci_dev *dev)
>  {
> -       if (!pci_match_id(port_runtime_pm_black_list, dev))
> -               pm_runtime_get_noresume(&dev->dev);
>         pcie_port_device_remove(dev);
>         pci_disable_device(dev);
>  }
>

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2013-04-03 22:38 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-23 14:33 [PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications Rafael J. Wysocki
2013-03-23 16:22 ` Matthew Garrett
2013-03-25 16:45 ` Sarah Sharp
2013-03-25 22:34   ` Rafael J. Wysocki
2013-03-28 17:10 ` [Resend][PATCH] " Rafael J. Wysocki
2013-03-28 21:07   ` [Update][PATCH] " Rafael J. Wysocki
2013-03-29 15:05     ` Martin Mokrejs
2013-03-29 16:05       ` Sarah Sharp
2013-03-29 17:11         ` Martin Mokrejs
2013-03-29 18:16           ` Martin Mokrejs
2013-03-29 21:37         ` Rafael J. Wysocki
2013-03-29 21:34       ` Rafael J. Wysocki
2013-04-03 22:38     ` Bjorn Helgaas
     [not found] ` <51548C9E.9090703@fold.natur.cuni.cz>
     [not found]   ` <2990024.LMTIBUbM3d@vostro.rjw.lan>
2013-03-30 22:38     ` [Update][PATCH] PCI / PM: Disable runtime PM of PCIe ports Rafael J. Wysocki
2013-04-01 17:34       ` Bjorn Helgaas
2013-04-01 20:51         ` Rafael J. Wysocki
2013-04-01 20:53           ` Bjorn Helgaas
2013-04-01 21:24             ` Rafael J. Wysocki
2013-04-01 23:20               ` Rafael J. Wysocki
2013-04-01 21:48             ` Martin Mokrejs
2013-04-02  5:34             ` huang ying
2013-04-02  5:28           ` huang ying
2013-04-02  5:31             ` huang ying
2013-04-03 22:34       ` Bjorn Helgaas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox