Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Bjørn Mork]

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

> It looks like both Ulrich and Andrew have the same issue.  I also have a
> Lenovo x220, and I confirmed that when I turn on PCI runtime suspend,
> the NEC host controller does not report port status changes when a new
> USB device is plugged in.
>
> I'm running 3.6.7, and I'm pretty sure that runtime suspend worked for
> the NEC host on some older kernel.  I don't think the NEC host went into
> D3cold on that kernel, though.  Is there a way to disable D3cold and
> just use D3hot instead?

Yes, you have /sys/bus/pci/devices/.../d3cold_allowed
See Documentation/ABI/testing/sysfs-bus-pci

If this really is a problem with the D3cold support that went into 3.6
then I guess you should include Huang Ying in the discussions as well
(CCed).


Bjørn

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Sarah Sharp]

On Mon, Nov 26, 2012 at 10:48:03PM +0100, Bjørn Mork wrote:
> Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> 
> > It looks like both Ulrich and Andrew have the same issue.  I also have a
> > Lenovo x220, and I confirmed that when I turn on PCI runtime suspend,
> > the NEC host controller does not report port status changes when a new
> > USB device is plugged in.
> >
> > I'm running 3.6.7, and I'm pretty sure that runtime suspend worked for
> > the NEC host on some older kernel.  I don't think the NEC host went into
> > D3cold on that kernel, though.  Is there a way to disable D3cold and
> > just use D3hot instead?
> 
> Yes, you have /sys/bus/pci/devices/.../d3cold_allowed
> See Documentation/ABI/testing/sysfs-bus-pci
> 
> If this really is a problem with the D3cold support that went into 3.6
> then I guess you should include Huang Ying in the discussions as well
> (CCed).

Turning off D3 cold didn't help.  Once the PCI device is suspended,
connect events do not generate an interrupt.

I'll go see if I can figure out which kernel this worked on and bisect.

Sarah Sharp

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Sarah Sharp]

On Wed, Nov 28, 2012 at 02:54:06PM -0800, Sarah Sharp wrote:
> On Mon, Nov 26, 2012 at 10:48:03PM +0100, Bjørn Mork wrote:
> > Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> > 
> > > It looks like both Ulrich and Andrew have the same issue.  I also have a
> > > Lenovo x220, and I confirmed that when I turn on PCI runtime suspend,
> > > the NEC host controller does not report port status changes when a new
> > > USB device is plugged in.
> > >
> > > I'm running 3.6.7, and I'm pretty sure that runtime suspend worked for
> > > the NEC host on some older kernel.  I don't think the NEC host went into
> > > D3cold on that kernel, though.  Is there a way to disable D3cold and
> > > just use D3hot instead?
> > 
> > Yes, you have /sys/bus/pci/devices/.../d3cold_allowed
> > See Documentation/ABI/testing/sysfs-bus-pci
> > 
> > If this really is a problem with the D3cold support that went into 3.6
> > then I guess you should include Huang Ying in the discussions as well
> > (CCed).
> 
> Turning off D3 cold didn't help.  Once the PCI device is suspended,
> connect events do not generate an interrupt.
> 
> I'll go see if I can figure out which kernel this worked on and bisect.

Wakeup from D3 works fine on the 3.5.0 kernel, but fails on 3.6.2.  I
haven't fully bisected yet.

In debugging, I found that if you only enable runtime suspend for the
NEC host controller, the host successfully comes out of D3 when you plug
in a USB device.  However, if you enable runtime PM for the parent PCIe root
port, it stops working.  Disabling D3cold for both devices did not help.

It looks like a PCI issue, so what sort of debugging info do you need
from me?

Sarah Sharp

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Rafael J. Wysocki]

On Wednesday, December 05, 2012 04:33:44 PM Sarah Sharp wrote:
> On Wed, Nov 28, 2012 at 02:54:06PM -0800, Sarah Sharp wrote:
> > On Mon, Nov 26, 2012 at 10:48:03PM +0100, Bjørn Mork wrote:
> > > Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> > > 
> > > > It looks like both Ulrich and Andrew have the same issue.  I also have a
> > > > Lenovo x220, and I confirmed that when I turn on PCI runtime suspend,
> > > > the NEC host controller does not report port status changes when a new
> > > > USB device is plugged in.
> > > >
> > > > I'm running 3.6.7, and I'm pretty sure that runtime suspend worked for
> > > > the NEC host on some older kernel.  I don't think the NEC host went into
> > > > D3cold on that kernel, though.  Is there a way to disable D3cold and
> > > > just use D3hot instead?
> > > 
> > > Yes, you have /sys/bus/pci/devices/.../d3cold_allowed
> > > See Documentation/ABI/testing/sysfs-bus-pci
> > > 
> > > If this really is a problem with the D3cold support that went into 3.6
> > > then I guess you should include Huang Ying in the discussions as well
> > > (CCed).
> > 
> > Turning off D3 cold didn't help.  Once the PCI device is suspended,
> > connect events do not generate an interrupt.
> > 
> > I'll go see if I can figure out which kernel this worked on and bisect.
> 
> Wakeup from D3 works fine on the 3.5.0 kernel, but fails on 3.6.2.  I
> haven't fully bisected yet.
> 
> In debugging, I found that if you only enable runtime suspend for the
> NEC host controller, the host successfully comes out of D3 when you plug
> in a USB device.  However, if you enable runtime PM for the parent PCIe root
> port, it stops working.  Disabling D3cold for both devices did not help.
> 
> It looks like a PCI issue, so what sort of debugging info do you need
> from me?

It looks like this is related to one of the following commits:

3d8387e PCI/PM: Fix config reg access for D3cold and bridge suspending
ea8c88f PCI/PM: Keep parent bridge active when probing device
4f9c139 PCI/PM: Enable D3/D3cold by default for most devices
448bd85 PCI/PM: add PCIe runtime D3cold support
71a83bd PCI/PM: add runtime PM support to PCIe port
ee85f54 ACPI/PM: specify lowest allowed state for device sleep state

Generally, please try to bisect changes in drivers/pci between v3.5 and v3.6.

Thanks,
Rafael


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

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Sarah Sharp]

On Thu, Dec 06, 2012 at 01:43:32AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, December 05, 2012 04:33:44 PM Sarah Sharp wrote:
> > Wakeup from D3 works fine on the 3.5.0 kernel, but fails on 3.6.2.  I
> > haven't fully bisected yet.
> > 
> > In debugging, I found that if you only enable runtime suspend for the
> > NEC host controller, the host successfully comes out of D3 when you plug
> > in a USB device.  However, if you enable runtime PM for the parent PCIe root
> > port, it stops working.  Disabling D3cold for both devices did not help.
> > 
> > It looks like a PCI issue, so what sort of debugging info do you need
> > from me?
> 
> It looks like this is related to one of the following commits:

> Generally, please try to bisect changes in drivers/pci between v3.5 and v3.6.

Ok, I ran git bisect with only the drivers/pci directory as a target.

> ee85f54 ACPI/PM: specify lowest allowed state for device sleep state

git bisect ended up identifying this as the bad patch, although
reverting just that patch after the bisect finished didn't seem to help.
However, it does make sense that this would be the culprit patch, if
Huang Ying's theory about the PME polling is correct.

Sarah Sharp

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Rafael J. Wysocki]

On Thursday, December 06, 2012 04:28:08 PM Sarah Sharp wrote:
> On Thu, Dec 06, 2012 at 01:43:32AM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, December 05, 2012 04:33:44 PM Sarah Sharp wrote:
> > > Wakeup from D3 works fine on the 3.5.0 kernel, but fails on 3.6.2.  I
> > > haven't fully bisected yet.
> > > 
> > > In debugging, I found that if you only enable runtime suspend for the
> > > NEC host controller, the host successfully comes out of D3 when you plug
> > > in a USB device.  However, if you enable runtime PM for the parent PCIe root
> > > port, it stops working.  Disabling D3cold for both devices did not help.
> > > 
> > > It looks like a PCI issue, so what sort of debugging info do you need
> > > from me?
> > 
> > It looks like this is related to one of the following commits:
> 
> > Generally, please try to bisect changes in drivers/pci between v3.5 and v3.6.
> 
> Ok, I ran git bisect with only the drivers/pci directory as a target.
> 
> > ee85f54 ACPI/PM: specify lowest allowed state for device sleep state
> 
> git bisect ended up identifying this as the bad patch, although
> reverting just that patch after the bisect finished didn't seem to help.
> However, it does make sense that this would be the culprit patch, if
> Huang Ying's theory about the PME polling is correct.

Well, we surely don't handle this particular case correctly, and it shouldn't
be very difficult to fix, so let's hope that this is the culprit. :-)

Thanks,
Rafael


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

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Huang Ying]

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

On Fri, 2012-12-07 at 22:00 +0100, Rafael J. Wysocki wrote:
> On Thursday, December 06, 2012 04:28:08 PM Sarah Sharp wrote:
> > On Thu, Dec 06, 2012 at 01:43:32AM +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, December 05, 2012 04:33:44 PM Sarah Sharp wrote:
> > > > Wakeup from D3 works fine on the 3.5.0 kernel, but fails on 3.6.2.  I
> > > > haven't fully bisected yet.
> > > > 
> > > > In debugging, I found that if you only enable runtime suspend for the
> > > > NEC host controller, the host successfully comes out of D3 when you plug
> > > > in a USB device.  However, if you enable runtime PM for the parent PCIe root
> > > > port, it stops working.  Disabling D3cold for both devices did not help.
> > > > 
> > > > It looks like a PCI issue, so what sort of debugging info do you need
> > > > from me?
> > > 
> > > It looks like this is related to one of the following commits:
> > 
> > > Generally, please try to bisect changes in drivers/pci between v3.5 and v3.6.
> > 
> > Ok, I ran git bisect with only the drivers/pci directory as a target.
> > 
> > > ee85f54 ACPI/PM: specify lowest allowed state for device sleep state
> > 
> > git bisect ended up identifying this as the bad patch, although
> > reverting just that patch after the bisect finished didn't seem to help.
> > However, it does make sense that this would be the culprit patch, if
> > Huang Ying's theory about the PME polling is correct.
> 
> Well, we surely don't handle this particular case correctly, and it shouldn't
> be very difficult to fix, so let's hope that this is the culprit. :-)
> 

Please try the patch attached.  With it, USB host controller can be
waken up with USB card reader plugging in on my test machine.

Best Regards,
Huang Ying


[-- Attachment #2: port_suspend_no_poll.patch --]
[-- Type: text/x-patch, Size: 1728 bytes --]

Subject: [BUGFIX] PCIe/PM: Do not suspend port if any subordinate device need PME polling

In

Ulrich reported that his USB3 cardreader does not work reliably when
connected to the USB3 port.  It turns out that USB3 controller failed
to be waken up when plugging in the USB3 cardreader.  Further
experiment found that the USB3 host controller can only be waken up
via polling, while not via PME interrupt.  But if the PCIe port the
USB3 host controller connected is suspended, we can not poll the USB3
host controller because its config space is not accessible if the PCIe
port is put into low power state.

To solve the issue, the PCIe port will not be suspended if any
subordinate device need PME polling.

Reported-by: Ulrich Eckhardt <usb@uli-eckhardt.de>
Signed-off-by: Huang Ying <ying.huang@intel.com>
---
 drivers/pci/pcie/portdrv_pci.c |   18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -134,10 +134,26 @@ static int pcie_port_runtime_resume(stru
 	return 0;
 }
 
+static int pci_dev_pme_poll(struct pci_dev *pdev, void *data)
+{
+	int *pme_poll = data;
+	*pme_poll = *pme_poll || pdev->pme_poll;
+	return 0;
+}
+
 static int pcie_port_runtime_idle(struct device *dev)
 {
+	struct pci_dev *pdev = to_pci_dev(dev);
+	int pme_poll = false;
+
+	/*
+	 * If any subordinate device needs pme poll, we should keep
+	 * the port in D0, because we need port in D0 to poll it.
+	 */
+	pci_walk_bus(pdev->subordinate, pci_dev_pme_poll, &pme_poll);
 	/* Delay for a short while to prevent too frequent suspend/resume */
-	pm_schedule_suspend(dev, 10);
+	if (!pme_poll)
+		pm_schedule_suspend(dev, 10);
 	return -EBUSY;
 }
 #else

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Andrew Lutomirski]

On Tue, Dec 11, 2012 at 6:32 PM, Huang Ying <ying.huang@intel.com> wrote:
> On Fri, 2012-12-07 at 22:00 +0100, Rafael J. Wysocki wrote:
>> On Thursday, December 06, 2012 04:28:08 PM Sarah Sharp wrote:
>> > On Thu, Dec 06, 2012 at 01:43:32AM +0100, Rafael J. Wysocki wrote:
>> > > On Wednesday, December 05, 2012 04:33:44 PM Sarah Sharp wrote:
>> > > > Wakeup from D3 works fine on the 3.5.0 kernel, but fails on 3.6.2.  I
>> > > > haven't fully bisected yet.
>> > > >
>> > > > In debugging, I found that if you only enable runtime suspend for the
>> > > > NEC host controller, the host successfully comes out of D3 when you plug
>> > > > in a USB device.  However, if you enable runtime PM for the parent PCIe root
>> > > > port, it stops working.  Disabling D3cold for both devices did not help.
>> > > >
>> > > > It looks like a PCI issue, so what sort of debugging info do you need
>> > > > from me?
>> > >
>> > > It looks like this is related to one of the following commits:
>> >
>> > > Generally, please try to bisect changes in drivers/pci between v3.5 and v3.6.
>> >
>> > Ok, I ran git bisect with only the drivers/pci directory as a target.
>> >
>> > > ee85f54 ACPI/PM: specify lowest allowed state for device sleep state
>> >
>> > git bisect ended up identifying this as the bad patch, although
>> > reverting just that patch after the bisect finished didn't seem to help.
>> > However, it does make sense that this would be the culprit patch, if
>> > Huang Ying's theory about the PME polling is correct.
>>
>> Well, we surely don't handle this particular case correctly, and it shouldn't
>> be very difficult to fix, so let's hope that this is the culprit. :-)
>>
>
> Please try the patch attached.  With it, USB host controller can be
> waken up with USB card reader plugging in on my test machine.

Potentially silly question: is this better than waking up the PCIe
port when polling the device (and putting it back to sleep again)?

--Andy

>
> Best Regards,
> Huang Ying
>

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[huang ying]

On Wed, Dec 12, 2012 at 10:34 AM, Andrew Lutomirski <luto@mit.edu> wrote:
> On Tue, Dec 11, 2012 at 6:32 PM, Huang Ying <ying.huang@intel.com> wrote:
>> On Fri, 2012-12-07 at 22:00 +0100, Rafael J. Wysocki wrote:
>>> On Thursday, December 06, 2012 04:28:08 PM Sarah Sharp wrote:
>>> > On Thu, Dec 06, 2012 at 01:43:32AM +0100, Rafael J. Wysocki wrote:
>>> > > On Wednesday, December 05, 2012 04:33:44 PM Sarah Sharp wrote:
>>> > > > Wakeup from D3 works fine on the 3.5.0 kernel, but fails on 3.6.2.  I
>>> > > > haven't fully bisected yet.
>>> > > >
>>> > > > In debugging, I found that if you only enable runtime suspend for the
>>> > > > NEC host controller, the host successfully comes out of D3 when you plug
>>> > > > in a USB device.  However, if you enable runtime PM for the parent PCIe root
>>> > > > port, it stops working.  Disabling D3cold for both devices did not help.
>>> > > >
>>> > > > It looks like a PCI issue, so what sort of debugging info do you need
>>> > > > from me?
>>> > >
>>> > > It looks like this is related to one of the following commits:
>>> >
>>> > > Generally, please try to bisect changes in drivers/pci between v3.5 and v3.6.
>>> >
>>> > Ok, I ran git bisect with only the drivers/pci directory as a target.
>>> >
>>> > > ee85f54 ACPI/PM: specify lowest allowed state for device sleep state
>>> >
>>> > git bisect ended up identifying this as the bad patch, although
>>> > reverting just that patch after the bisect finished didn't seem to help.
>>> > However, it does make sense that this would be the culprit patch, if
>>> > Huang Ying's theory about the PME polling is correct.
>>>
>>> Well, we surely don't handle this particular case correctly, and it shouldn't
>>> be very difficult to fix, so let's hope that this is the culprit. :-)
>>>
>>
>> Please try the patch attached.  With it, USB host controller can be
>> waken up with USB card reader plugging in on my test machine.
>
> Potentially silly question: is this better than waking up the PCIe
> port when polling the device (and putting it back to sleep again)?

Put PCI devices into/out of low power state can be very time
consuming.  For D3hot, it is at least 20ms, and for D3cold, it is at
least 200ms.

Best Regards,
Huang Ying

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Sarah Sharp]

On Wed, Dec 12, 2012 at 10:32:05AM +0800, Huang Ying wrote:
> Please try the patch attached.  With it, USB host controller can be
> waken up with USB card reader plugging in on my test machine.

This patch works for me.  When I enable runtime PM for both the root port
and the host controller, and I see the xHCI host go into PCI runtime
suspend, but there's no longer a message about the power state changing
to D3cold.  USB device connects while the PCI host is suspended work
now, as well as remote wakeup.

Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

Please mark this for stable.

Thanks,
Sarah Sharp

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Huang Ying]

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

On Wed, 2012-12-05 at 16:33 -0800, Sarah Sharp wrote:
> On Wed, Nov 28, 2012 at 02:54:06PM -0800, Sarah Sharp wrote:
> > On Mon, Nov 26, 2012 at 10:48:03PM +0100, Bjørn Mork wrote:
> > > Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> > > 
> > > > It looks like both Ulrich and Andrew have the same issue.  I also have a
> > > > Lenovo x220, and I confirmed that when I turn on PCI runtime suspend,
> > > > the NEC host controller does not report port status changes when a new
> > > > USB device is plugged in.
> > > >
> > > > I'm running 3.6.7, and I'm pretty sure that runtime suspend worked for
> > > > the NEC host on some older kernel.  I don't think the NEC host went into
> > > > D3cold on that kernel, though.  Is there a way to disable D3cold and
> > > > just use D3hot instead?
> > > 
> > > Yes, you have /sys/bus/pci/devices/.../d3cold_allowed
> > > See Documentation/ABI/testing/sysfs-bus-pci
> > > 
> > > If this really is a problem with the D3cold support that went into 3.6
> > > then I guess you should include Huang Ying in the discussions as well
> > > (CCed).
> > 
> > Turning off D3 cold didn't help.  Once the PCI device is suspended,
> > connect events do not generate an interrupt.
> > 
> > I'll go see if I can figure out which kernel this worked on and bisect.
> 
> Wakeup from D3 works fine on the 3.5.0 kernel, but fails on 3.6.2.  I
> haven't fully bisected yet.
> 
> In debugging, I found that if you only enable runtime suspend for the
> NEC host controller, the host successfully comes out of D3 when you plug
> in a USB device.  However, if you enable runtime PM for the parent PCIe root
> port, it stops working.  Disabling D3cold for both devices did not help.
> 
> It looks like a PCI issue, so what sort of debugging info do you need
> from me?

I do some debug with my NEC uPD720200, the patch is attached.  I found
that NEC uPD720200 can not generate PME interrupt, so it can be remote
waken up only via polling.  But if the PCIe bridge connected to NEC
uPD720200 goes into suspended, we can not poll it.  Maybe we need a way
to disable PCIe bridge suspended if the underlying device can only be
waken up via polling.

Best Regards,
Huang Ying


[-- Attachment #2: dbg_poll.patch --]
[-- Type: text/x-patch, Size: 2100 bytes --]

Index: linux.git/drivers/pci/pci.c
===================================================================
--- linux.git.orig/drivers/pci/pci.c	2012-12-06 10:57:31.485231614 +0800
+++ linux.git/drivers/pci/pci.c	2012-12-06 10:57:31.541230913 +0800
@@ -1473,12 +1473,15 @@
 		dev->pme_poll = false;
 
 	if (pci_check_pme_status(dev)) {
+		if (pme_poll_reset)
+			dev_info(&dev->dev, "pme wakeup\n");
+		else
+			dev_info(&dev->dev, "poll wakeup\n");
 		pci_wakeup_event(dev);
 		pm_request_resume(&dev->dev);
 	}
 	return 0;
 }
-
 /**
  * pci_pme_wakeup_bus - Walk given bus and wake up devices on it, if necessary.
  * @bus: Top bus of the subtree to walk.
Index: linux.git/drivers/pci/pci-acpi.c
===================================================================
--- linux.git.orig/drivers/pci/pci-acpi.c	2012-12-06 10:57:31.485231614 +0800
+++ linux.git/drivers/pci/pci-acpi.c	2012-12-06 10:57:31.542230901 +0800
@@ -56,6 +56,7 @@
 
 	if (!pci_dev->pm_cap || !pci_dev->pme_support
 	     || pci_check_pme_status(pci_dev)) {
+		dev_info(&pci_dev->dev, "pme wakeup\n");
 		if (pci_dev->pme_poll)
 			pci_dev->pme_poll = false;
 
Index: linux.git/drivers/pci/pcie/pme.c
===================================================================
--- linux.git.orig/drivers/pci/pcie/pme.c	2012-12-06 10:57:31.485231614 +0800
+++ linux.git/drivers/pci/pcie/pme.c	2012-12-06 10:57:31.542230901 +0800
@@ -79,6 +79,7 @@
 	list_for_each_entry(dev, &bus->devices, bus_list) {
 		/* Skip PCIe devices in case we started from a root port. */
 		if (!pci_is_pcie(dev) && pci_check_pme_status(dev)) {
+			dev_info(&dev->dev, "pme wakeup\n");
 			if (dev->pme_poll)
 				dev->pme_poll = false;
 
@@ -144,6 +145,7 @@
 			port->pme_poll = false;
 
 		if (pci_check_pme_status(port)) {
+			dev_info(&dev->dev, "pme wakeup\n");
 			pm_request_resume(&port->dev);
 			found = true;
 		} else {
@@ -188,6 +190,7 @@
 		/* The device is there, but we have to check its PME status. */
 		found = pci_check_pme_status(dev);
 		if (found) {
+			dev_info(&dev->dev, "pme wakeup\n");
 			if (dev->pme_poll)
 				dev->pme_poll = false;
 

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Rafael J. Wysocki]

On Thursday, December 06, 2012 03:17:14 PM Huang Ying wrote:
> On Wed, 2012-12-05 at 16:33 -0800, Sarah Sharp wrote:
> > On Wed, Nov 28, 2012 at 02:54:06PM -0800, Sarah Sharp wrote:
> > > On Mon, Nov 26, 2012 at 10:48:03PM +0100, Bjørn Mork wrote:
> > > > Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> > > > 
> > > > > It looks like both Ulrich and Andrew have the same issue.  I also have a
> > > > > Lenovo x220, and I confirmed that when I turn on PCI runtime suspend,
> > > > > the NEC host controller does not report port status changes when a new
> > > > > USB device is plugged in.
> > > > >
> > > > > I'm running 3.6.7, and I'm pretty sure that runtime suspend worked for
> > > > > the NEC host on some older kernel.  I don't think the NEC host went into
> > > > > D3cold on that kernel, though.  Is there a way to disable D3cold and
> > > > > just use D3hot instead?
> > > > 
> > > > Yes, you have /sys/bus/pci/devices/.../d3cold_allowed
> > > > See Documentation/ABI/testing/sysfs-bus-pci
> > > > 
> > > > If this really is a problem with the D3cold support that went into 3.6
> > > > then I guess you should include Huang Ying in the discussions as well
> > > > (CCed).
> > > 
> > > Turning off D3 cold didn't help.  Once the PCI device is suspended,
> > > connect events do not generate an interrupt.
> > > 
> > > I'll go see if I can figure out which kernel this worked on and bisect.
> > 
> > Wakeup from D3 works fine on the 3.5.0 kernel, but fails on 3.6.2.  I
> > haven't fully bisected yet.
> > 
> > In debugging, I found that if you only enable runtime suspend for the
> > NEC host controller, the host successfully comes out of D3 when you plug
> > in a USB device.  However, if you enable runtime PM for the parent PCIe root
> > port, it stops working.  Disabling D3cold for both devices did not help.
> > 
> > It looks like a PCI issue, so what sort of debugging info do you need
> > from me?
> 
> I do some debug with my NEC uPD720200, the patch is attached.  I found
> that NEC uPD720200 can not generate PME interrupt, so it can be remote
> waken up only via polling.  But if the PCIe bridge connected to NEC
> uPD720200 goes into suspended, we can not poll it.  Maybe we need a way
> to disable PCIe bridge suspended if the underlying device can only be
> waken up via polling.

I think we need to be more intelligent about that.  It looks like we can
only suspend a port (or bridge in general) if all devices below it have
the pme_poll flag unset.

Thanks,
Rafael


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

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Sarah Sharp]

On Sun, Oct 21, 2012 at 06:03:24PM +0200, Ulrich Eckhardt wrote:
> Hello,
> 
> I have problems to get my USB3 cardreader to work reliably when
> connected to the USB3 port. Due to lack of other USB3 devices I
> don't know if it is the cardreader or the USB3 host (NEC uPD720200)
> but the cardreader always works reliable when connected to USB2.
> 
> Sometimes it is not possible to use the cardreader directly after
> power up and I have to restart the computer. Very often the
> cardreader stops working after removing a SD-card and insert another
> SD-card or during copying data.
> 
> I have tested it with Kernel 3.6.2. The USB3 port is the one built
> in the Mainboard M4A87DT EVO.

Did a previous kernel version work?

> I saw, that the outputs of lspci are different, if there is a
> problem directly after startup.

Bjorn, can you take a look at this PCI output, and tell me if it matters
that the host has bus master and latency 0 when it works and is missing
those properties when it doesn't?

Does the lspci differ when booting the same kernel, or is the lspci from
two different kernels?

> When the port is working:
> 04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
> Controller (rev 03) (prog-if 30 [XHCI])
>         Subsystem: NEC Corporation uPD720200 USB 3.0 Host Controller
>         Flags: bus master, fast devsel, latency 0, IRQ 18
>         Memory at f9efe000 (64-bit, non-prefetchable) [size=8K]
>         Capabilities: [50] Power Management version 3
>         Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
>         Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
>         Capabilities: [a0] Express Endpoint, MSI 00
>         Capabilities: [100] Advanced Error Reporting
>         Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff
>         Capabilities: [150] Latency Tolerance Reporting
>         Kernel driver in use: xhci_hcd
> 
> When the port is not working:
> 04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
> Controller (rev 03) (prog-if 30 [XHCI])
>         Subsystem: NEC Corporation uPD720200 USB 3.0 Host Controller
>         Flags: fast devsel, IRQ 18
>         Memory at f9efe000 (64-bit, non-prefetchable) [disabled][size=8K]
>         Capabilities: [50] Power Management version 3
>         Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
>         Capabilities: [90] MSI-X: Enable- Count=8 Masked-
>         Capabilities: [a0] Express Endpoint, MSI 00
>         Capabilities: [100] Advanced Error Reporting
>         Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff
>         Capabilities: [150] Latency Tolerance Reporting
> 
> A dmesg output, when the cardreader stops after removing the SD-card:
> [  483.143351] hub 9-0:1.0: cannot reset port 2 (err = -19)
> [  483.143398] hub 9-0:1.0: hub_port_status failed (err = -19)
> [  483.143433] sd 10:0:0:4: Device offlined - not ready after error recovery
> [  586.083402] sdf: detected capacity change from 2032664576 to 0
> 
> 
> Here is a dmesg output, when the cardreader stops working during
> copying data:

Is there anything before that line in the dmesg?  Because it seems that
the whole xHCI host gets unregistered, and it would be good to know why.

Sarah Sharp

> [  787.343581] usb 9-2: USB disconnect, device number 2
> [  831.620551] xhci_hcd 0000:04:00.0: remove, state 4
> [  831.620604] usb usb9: USB disconnect, device number 1
> [  831.620742] xHCI xhci_drop_endpoint called for root hub
> [  831.620746] xHCI xhci_check_bandwidth called for root hub
> [  831.629149] xhci_hcd 0000:04:00.0: USB bus 9 deregistered
> [  831.629182] xhci_hcd 0000:04:00.0: remove, state 4
> [  831.629192] usb usb8: USB disconnect, device number 1
> [  831.629284] xHCI xhci_drop_endpoint called for root hub
> [  831.629287] xHCI xhci_check_bandwidth called for root hub
> [  831.733941] xhci_hcd 0000:04:00.0: USB bus 8 deregistered
> [  833.765457] xhci_hcd 0000:04:00.0: xHCI Host Controller
> [  833.765484] xhci_hcd 0000:04:00.0: new USB bus registered,
> assigned bus number 8
> [  833.869813] xhci_hcd 0000:04:00.0: irq 18, io mem 0xf9efe000
> [  833.869893] xhci_hcd 0000:04:00.0: irq 46 for MSI/MSI-X
> [  833.869909] xhci_hcd 0000:04:00.0: irq 47 for MSI/MSI-X
> [  833.869925] xhci_hcd 0000:04:00.0: irq 48 for MSI/MSI-X
> [  833.869940] xhci_hcd 0000:04:00.0: irq 49 for MSI/MSI-X
> [  833.869954] xhci_hcd 0000:04:00.0: irq 50 for MSI/MSI-X
> [  833.869969] xhci_hcd 0000:04:00.0: irq 51 for MSI/MSI-X
> [  833.869983] xhci_hcd 0000:04:00.0: irq 52 for MSI/MSI-X
> [  833.870170] usb usb8: New USB device found, idVendor=1d6b, idProduct=0002
> [  833.870177] usb usb8: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [  833.870183] usb usb8: Product: xHCI Host Controller
> [  833.870188] usb usb8: Manufacturer: Linux 3.6.2-ue-desktop xhci_hcd
> [  833.870192] usb usb8: SerialNumber: 0000:04:00.0
> [  833.870430] xHCI xhci_add_endpoint called for root hub
> [  833.870435] xHCI xhci_check_bandwidth called for root hub
> [  833.870503] hub 8-0:1.0: USB hub found
> [  833.870515] hub 8-0:1.0: 2 ports detected
> [  833.900727] xhci_hcd 0000:04:00.0: xHCI Host Controller
> [  833.900743] xhci_hcd 0000:04:00.0: new USB bus registered,
> assigned bus number 9
> [  833.900811] usb usb9: New USB device found, idVendor=1d6b, idProduct=0003
> [  833.900818] usb usb9: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [  833.900823] usb usb9: Product: xHCI Host Controller
> [  833.900828] usb usb9: Manufacturer: Linux 3.6.2-ue-desktop xhci_hcd
> [  833.900833] usb usb9: SerialNumber: 0000:04:00.0
> [  833.901058] xHCI xhci_add_endpoint called for root hub
> [  833.901062] xHCI xhci_check_bandwidth called for root hub
> [  833.901129] hub 9-0:1.0: USB hub found
> [  833.901145] hub 9-0:1.0: 2 ports detected
> [  834.207292] usb 9-2: new SuperSpeed USB device number 2 using xhci_hcd
> [  834.226262] usb 9-2: Parent hub missing LPM exit latency info.
> Power management will be impacted.
> [  834.323600] usb 9-2: New USB device found, idVendor=0bda, idProduct=0301
> [  834.323611] usb 9-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [  834.323617] usb 9-2: Product: USB3.0 Card Reader
> [  834.323622] usb 9-2: Manufacturer: Realtek
> [  834.323627] usb 9-2: SerialNumber: 201006010301
> [  834.330317] scsi11 : usb-storage 9-2:1.0
> [  835.347621] scsi 11:0:0:0: Direct-Access     Generic- USB3.0
> CRW-CF/MD 1.00 PQ: 0 ANSI: 0 CCS
> [  835.363575] scsi 11:0:0:1: Direct-Access     Generic- USB3.0
> CRW-SM/xD 1.00 PQ: 0 ANSI: 0 CCS
> [  835.379999] scsi 11:0:0:2: Direct-Access     Generic- USB3.0
> CRW-SD   1.00 PQ: 0 ANSI: 0 CCS
> [  835.396476] scsi 11:0:0:3: Direct-Access     Generic- USB3.0
> CRW-MS   1.00 PQ: 0 ANSI: 0 CCS
> [  835.412459] scsi 11:0:0:4: Direct-Access     Generic- USB3.0
> CRW-SD/MS 1.00 PQ: 0 ANSI: 0 CCS
> [  835.414504] sd 11:0:0:0: Attached scsi generic sg4 type 0
> [  835.414809] sd 11:0:0:1: Attached scsi generic sg5 type 0
> [  835.415100] sd 11:0:0:2: Attached scsi generic sg6 type 0
> [  835.415319] sd 11:0:0:3: Attached scsi generic sg7 type 0
> [  835.415514] sd 11:0:0:4: Attached scsi generic sg8 type 0
> [  835.644755] sd 11:0:0:2: [sdf] Attached SCSI removable disk
> [  835.649335] sd 11:0:0:4: [sdh] Attached SCSI removable disk
> [  835.661916] sd 11:0:0:1: [sde] Attached SCSI removable disk
> [  835.670545] sd 11:0:0:0: [sdd] Attached SCSI removable disk
> [  835.674558] sd 11:0:0:3: [sdg] Attached SCSI removable disk
> [  844.984896] sd 11:0:0:2: [sdf] 3970048 512-byte logical blocks:
> (2.03 GB/1.89 GiB)
> [  844.986038] sd 11:0:0:2: [sdf] No Caching mode page present
> [  844.986049] sd 11:0:0:2: [sdf] Assuming drive cache: write through
> [  844.989503] sd 11:0:0:2: [sdf] No Caching mode page present
> [  844.989513] sd 11:0:0:2: [sdf] Assuming drive cache: write through
> [  844.991736]  sdf: sdf1
> [  912.223693] Clocksource tsc unstable (delta = -128663206 ns)
> [  912.223700] hub 9-0:1.0: cannot reset port 2 (err = -19)
> [  912.223772] Switching to clocksource hpet
> [  912.485117] sd 11:0:0:2: Device offlined - not ready after error recovery
> [  912.485128] sd 11:0:0:2: [sdf] Unhandled error code
> [  912.485129] sd 11:0:0:2: [sdf]
> [  912.485131] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
> [  912.485132] sd 11:0:0:2: [sdf] CDB:
> [  912.485133] Read(10): 28 00 00 34 c7 80 00 00 f0 00
> [  912.485139] end_request: I/O error, dev sdf, sector 3458944
> [  912.485169] sd 11:0:0:2: rejecting I/O to offline device
> [  912.485172] sd 11:0:0:2: killing request
> [  912.485193] sd 11:0:0:2: rejecting I/O to offline device
> [  912.485194] sd 11:0:0:2: [sdf] killing request
> [  912.485199] sd 11:0:0:2: rejecting I/O to offline device
> [  912.485206] sd 11:0:0:2: rejecting I/O to offline device
> [  912.485208] sd 11:0:0:2: rejecting I/O to offline device
> [  912.485215] sd 11:0:0:2: [sdf] Unhandled error code
> [  912.485217] sd 11:0:0:2: [sdf]
> [  912.485218] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
> [  912.485220] sd 11:0:0:2: [sdf] CDB:
> [  912.485221] Read(10): 28 00 00 34 c8 70 00 00 10 00
> [  912.485231] end_request: I/O error, dev sdf, sector 3459184
> [  912.485249] sd 11:0:0:2: rejecting I/O to offline device
> [  912.485439] hub 9-0:1.0: hub_port_status failed (err = -19)
> [  912.493691] sd 11:0:0:2: rejecting I/O to offline device
> 
> 
> The lsusb-output of the Cardreader from Delock
> lsusb -v -s 9:
> 
> Bus 009 Device 002: ID 0bda:0301 Realtek Semiconductor Corp.
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               3.00
>   bDeviceClass            0 (Defined at Interface level)
>   bDeviceSubClass         0
>   bDeviceProtocol         0
>   bMaxPacketSize0         9
>   idVendor           0x0bda Realtek Semiconductor Corp.
>   idProduct          0x0301
>   bcdDevice            1.20
>   iManufacturer           1 Realtek
>   iProduct                2 USB3.0 Card Reader
>   iSerial                 3 201006010301
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           44
>     bNumInterfaces          1
>     bConfigurationValue     1
>     iConfiguration          4 CARD READER
>     bmAttributes         0x80
>       (Bus Powered)
>     MaxPower              200mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass         8 Mass Storage
>       bInterfaceSubClass      6 SCSI
>       bInterfaceProtocol     80 Bulk (Zip)
>       iInterface              5 Bulk-In, Bulk-Out, Interface
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x01  EP 1 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>     wMaxPacketSize     0x0400  1x 1024 bytes
>         bInterval               0
>         bMaxBurst               3
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x82  EP 2 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0400  1x 1024 bytes
>         bInterval               0
>         bMaxBurst               3
> inary Object Store Descriptor:
>   bLength                 5
>   bDescriptorType        15
>   wTotalLength           22
>   bNumDeviceCaps          2
>   USB 2.0 Extension Device Capability:
>     bLength                 7
>     bDescriptorType        16
>     bDevCapabilityType      2
>     bmAttributes   0x00000002
>       Link Power Management (LPM) Supported
>   SuperSpeed USB Device Capability:
>     bLength                10
>     bDescriptorType        16
>     bDevCapabilityType      3
>     bmAttributes         0x00
>       Latency Tolerance Messages (LTM) Supported
>     wSpeedsSupported   0x000e
>       Device can operate at Full Speed (12Mbps)
>       Device can operate at High Speed (480Mbps)
>       Device can operate at SuperSpeed (5Gbps)
>     bFunctionalitySupport   0
>       Lowest fully-functional device speed is Low Speed (1Mbps)
>     bU1DevExitLat           1 micro seconds
>     bU2DevExitLat        2815 micro seconds
> Device Status:     0x0000
>   (Bus Powered)
> Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               3.00
>   bDeviceClass            9 Hub
>   bDeviceSubClass         0 Unused
>   bDeviceProtocol         3
>   bMaxPacketSize0         9
>   idVendor           0x1d6b Linux Foundation
>   idProduct          0x0003 3.0 root hub
>   bcdDevice            3.06
>   iManufacturer           3 Linux 3.6.2-ue-desktop xhci_hcd
>   iProduct                2 xHCI Host Controller
>   iSerial                 1 0000:04:00.0
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           31
>     bNumInterfaces          1
>     bConfigurationValue     1
>     iConfiguration          0
>     bmAttributes         0xe0
>       Self Powered
>       Remote Wakeup
>     MaxPower                0mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           1
>       bInterfaceClass         9 Hub
>       bInterfaceSubClass      0 Unused
>       bInterfaceProtocol      0 Full speed (or root) hub
>       iInterface              0
>       Endpoint Descriptor:
>    bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x81  EP 1 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0004  1x 4 bytes
>         bInterval              12
>         bMaxBurst               0
> Hub Descriptor:
>   bLength              12
>   bDescriptorType      42
>   nNbrPorts             2
>   wHubCharacteristic 0x0009
>     Per-port power switching
>     Per-port overcurrent protection
>   bPwrOn2PwrGood       10 * 2 milli seconds
>   bHubContrCurrent      0 milli Ampere
>   bHubDecLat          0.0 micro seconds
>   wHubDelay             0 nano seconds
>   DeviceRemovable    0x00
>  Hub Port Status:
>    Port 1: 0000.02a0 5Gbps power Rx.Detect
>    Port 2: 0000.0203 5Gbps power U0 enable connect
> Binary Object Store Descriptor:
>   bLength                 5
>   bDescriptorType        15
>   wTotalLength           15
>   bNumDeviceCaps          1
>   SuperSpeed USB Device Capability:
>     bLength                10
>     bDescriptorType        16
>     bDevCapabilityType      3
>     bmAttributes         0x02
>     wSpeedsSupported   0x0008
>       Device can operate at SuperSpeed (5Gbps)
>     bFunctionalitySupport   0
>   Lowest fully-functional device speed is Low Speed (1Mbps)
>     bU1DevExitLat           3 micro seconds
>     bU2DevExitLat           0 micro seconds
> Device Status:     0x0001
>   Self Powered
> 
> An output of lspci of my system:
> lspci
> 00:00.0 Host bridge: Advanced Micro Devices [AMD] nee ATI
> RX780/RX790 Chipset Host Bridge
> 00:02.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD790 PCI
> to PCI bridge (external gfx0 port A)
> 00:09.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD790 PCI
> to PCI bridge (PCI express gpp port E)
> 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD790 PCI
> to PCI bridge (PCI express gpp port F)
> 00:11.0 SATA controller: Advanced Micro Devices [AMD] nee ATI
> SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (rev 40)
> 00:12.0 USB controller: Advanced Micro Devices [AMD] nee ATI
> SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
> 00:12.2 USB controller: Advanced Micro Devices [AMD] nee ATI
> SB7x0/SB8x0/SB9x0 USB EHCI Controller
> 00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI
> SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
> 00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI
> SB7x0/SB8x0/SB9x0 USB EHCI Controller
> 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus
> Controller (rev 41)
> 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00
> Azalia (Intel HDA) (rev 40)
> 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI
> SB7x0/SB8x0/SB9x0 LPC host controller (rev 40)
> 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI
> to PCI Bridge (rev 40)
> 00:14.5 USB controller: Advanced Micro Devices [AMD] nee ATI
> SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
> 00:15.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI
> SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0)
> 00:15.1 PCI bridge: Advanced Micro Devices [AMD] nee ATI
> SB700/SB800/SB900 PCI to PCI bridge (PCIE port 1)
> 00:16.0 USB controller: Advanced Micro Devices [AMD] nee ATI
> SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
> 00:16.2 USB controller: Advanced Micro Devices [AMD] nee ATI
> SB7x0/SB8x0/SB9x0 USB EHCI Controller
> 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h
> Processor HyperTransport Configuration
> 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h
> Processor Address Map
> 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h
> Processor DRAM Controller
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h
> Processor Miscellaneous Control
> 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h
> Processor Link Control
> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
> 02:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885
> PCI Video and Audio Decoder (rev 02)
> 04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
> Controller (rev ff)
> 05:00.0 SATA controller: JMicron Technology Corp. JMB361 AHCI/IDE (rev 02)
> 05:00.1 IDE interface: JMicron Technology Corp. JMB361 AHCI/IDE (rev 02)
> 06:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce
> 8400 GS] (rev a1)
> 
> lsusb
> Bus 001 Device 002: ID 0451:8042 Texas Instruments, Inc.
> Bus 009 Device 002: ID 0bda:0301 Realtek Semiconductor Corp.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 003: ID 046d:c050 Logitech, Inc. RX 250 Optical Mouse
> 
> 
> 
> -- 
> Ulrich Eckhardt                  http://www.uli-eckhardt.de
> 
> Ein Blitzableiter auf dem Kirchturm ist das denkbar stärkste
> Misstrauensvotum gegen den lieben Gott. (Karl Krauss)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Bjorn Helgaas]

On Mon, Oct 22, 2012 at 5:40 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> On Sun, Oct 21, 2012 at 06:03:24PM +0200, Ulrich Eckhardt wrote:
>> Hello,
>>
>> I have problems to get my USB3 cardreader to work reliably when
>> connected to the USB3 port. Due to lack of other USB3 devices I
>> don't know if it is the cardreader or the USB3 host (NEC uPD720200)
>> but the cardreader always works reliable when connected to USB2.
>>
>> Sometimes it is not possible to use the cardreader directly after
>> power up and I have to restart the computer. Very often the
>> cardreader stops working after removing a SD-card and insert another
>> SD-card or during copying data.
>>
>> I have tested it with Kernel 3.6.2. The USB3 port is the one built
>> in the Mainboard M4A87DT EVO.
>
> Did a previous kernel version work?
>
>> I saw, that the outputs of lspci are different, if there is a
>> problem directly after startup.
>
> Bjorn, can you take a look at this PCI output, and tell me if it matters
> that the host has bus master and latency 0 when it works and is missing
> those properties when it doesn't?

Yes, I would think that would matter.  If the Bus Master bit in the
command register isn't set, the device won't be able to DMA.  Also, it
looks like the memory BAR is disabled (probably the Memory Space bit
in the command register is also cleared).

My guess is that these are just a consequence of the driver being
detached from the device for some reason.

It'd be nice to have a complete dmesg log for a case where the device
worked, then stopped working.  Also "lspci -vv" for both cases.

Bjorn

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Ulrich Eckhardt]

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

Am 23.10.2012 01:40, schrieb Sarah Sharp:
> On Sun, Oct 21, 2012 at 06:03:24PM +0200, Ulrich Eckhardt wrote:

>> I have tested it with Kernel 3.6.2. The USB3 port is the one built
>> in the Mainboard M4A87DT EVO.
>
> Did a previous kernel version work?

Yes, I tried the Kernel shipped with OpenSUSE (3.4.11) several 3.5 and 
all available 3.6 kernel versions.

>> Here is a dmesg output, when the cardreader stops working during
>> copying data:
>
> Is there anything before that line in the dmesg?  Because it seems that
> the whole xHCI host gets unregistered, and it would be good to know why.

I attach the complete dmesg logs and the lspci -vv output as requested 
by Bjorn for the situations when the controller does not work after 
startup (extension notworking), when the controller is working 
(extension OK), and after stopping (extension stop).

Due to the size, I have gziped the log files. I hope this is OK for you.

Best Regards
Uli
-- 
Ulrich Eckhardt                  http://www.uli-eckhardt.de

Ein Blitzableiter auf dem Kirchturm ist das denkbar stärkste
Misstrauensvotum gegen den lieben Gott. (Karl Krauss)

[-- Attachment #2: dmesg.notworking.gz --]
[-- Type: application/x-gunzip, Size: 16736 bytes --]

[-- Attachment #3: dmesg.OK.gz --]
[-- Type: application/x-gunzip, Size: 16618 bytes --]

[-- Attachment #4: dmesg.stop.gz --]
[-- Type: application/x-gunzip, Size: 16853 bytes --]

[-- Attachment #5: lspci.notworking.gz --]
[-- Type: application/x-gunzip, Size: 5095 bytes --]

[-- Attachment #6: lspci.OK.gz --]
[-- Type: application/x-gunzip, Size: 5253 bytes --]

[-- Attachment #7: lspci.stop.gz --]
[-- Type: application/x-gunzip, Size: 5255 bytes --]

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Bjorn Helgaas]

On Tue, Oct 23, 2012 at 11:14 AM, Ulrich Eckhardt <usb@uli-eckhardt.de> wrote:
> Am 23.10.2012 01:40, schrieb Sarah Sharp:
>> On Sun, Oct 21, 2012 at 06:03:24PM +0200, Ulrich Eckhardt wrote:
>
>>> I have tested it with Kernel 3.6.2. The USB3 port is the one built
>>> in the Mainboard M4A87DT EVO.
>>
>> Did a previous kernel version work?
>
> Yes, I tried the Kernel shipped with OpenSUSE (3.4.11) several 3.5 and all
> available 3.6 kernel versions.

I assume you mean that every kernel you tried failed?  If some
kernel(s) did work, what is the newest working version and the oldest
broken version?

> I attach the complete dmesg logs and the lspci -vv output as requested by
> Bjorn for the situations when the controller does not work after startup
> (extension notworking), when the controller is working (extension OK), and
> after stopping (extension stop).

In the "notworking" logs, my guess is that the xHCI device is being
powered off.  The "notworking" lspci shows this:

  00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD790 PCI
to PCI bridge (PCI express gpp port F) (prog-if 00 [Normal decode])
        Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
                LnkCap: Port #247, Speed 5GT/s, Width x2, ASPM L0s L1,
Latency L0 <64ns, L1 <1us
                LnkSta: Speed unknown, Width x1, TrErr- Train-
SlotClk+ DLActive- BWMgmt+ ABWMgmt+
  04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
Controller (rev ff) (prog-if ff)
        !!! Unknown header type 7f
        Kernel driver in use: xhci_hcd

The bridge's "DLActive-" means that the downstream link leading to the
xHCI device is not active.  The "rev ff", "prog-if ff", and "header
type 7f" suggest that we read all 0xff's from the xHCI device, which
is what we get if the device doesn't respond.

The xHCI device must have been powered up and working originally,
because we enumerated it and bound the xhci_hcd driver to it.  I don't
have any ideas about why it would be powered off.

Rafael, Alan, is there any way we can disable power management or
enable related debug messages?

Bjorn

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Rafael J. Wysocki]

On Wednesday 24 of October 2012 14:18:40 Bjorn Helgaas wrote:
> On Tue, Oct 23, 2012 at 11:14 AM, Ulrich Eckhardt <usb@uli-eckhardt.de> wrote:
> > Am 23.10.2012 01:40, schrieb Sarah Sharp:
> >> On Sun, Oct 21, 2012 at 06:03:24PM +0200, Ulrich Eckhardt wrote:
> >
> >>> I have tested it with Kernel 3.6.2. The USB3 port is the one built
> >>> in the Mainboard M4A87DT EVO.
> >>
> >> Did a previous kernel version work?
> >
> > Yes, I tried the Kernel shipped with OpenSUSE (3.4.11) several 3.5 and all
> > available 3.6 kernel versions.
> 
> I assume you mean that every kernel you tried failed?  If some
> kernel(s) did work, what is the newest working version and the oldest
> broken version?
> 
> > I attach the complete dmesg logs and the lspci -vv output as requested by
> > Bjorn for the situations when the controller does not work after startup
> > (extension notworking), when the controller is working (extension OK), and
> > after stopping (extension stop).
> 
> In the "notworking" logs, my guess is that the xHCI device is being
> powered off.  The "notworking" lspci shows this:
> 
>   00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD790 PCI
> to PCI bridge (PCI express gpp port F) (prog-if 00 [Normal decode])
>         Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
>                 LnkCap: Port #247, Speed 5GT/s, Width x2, ASPM L0s L1,
> Latency L0 <64ns, L1 <1us
>                 LnkSta: Speed unknown, Width x1, TrErr- Train-
> SlotClk+ DLActive- BWMgmt+ ABWMgmt+
>   04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
> Controller (rev ff) (prog-if ff)
>         !!! Unknown header type 7f
>         Kernel driver in use: xhci_hcd
> 
> The bridge's "DLActive-" means that the downstream link leading to the
> xHCI device is not active.  The "rev ff", "prog-if ff", and "header
> type 7f" suggest that we read all 0xff's from the xHCI device, which
> is what we get if the device doesn't respond.
> 
> The xHCI device must have been powered up and working originally,
> because we enumerated it and bound the xhci_hcd driver to it.  I don't
> have any ideas about why it would be powered off.
> 
> Rafael, Alan, is there any way we can disable power management or
> enable related debug messages?

It can be disabled by writing "on" to the controller's
/sys/devices/.../power/control file.

For debug, there are trace points in rpm_suspend() and rpm_resume().

That's if we're talking about runtime PM, of course.

Thanks,
Rafael


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

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Bjorn Helgaas]

On Wed, Oct 24, 2012 at 3:10 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Wednesday 24 of October 2012 14:18:40 Bjorn Helgaas wrote:
>> On Tue, Oct 23, 2012 at 11:14 AM, Ulrich Eckhardt <usb@uli-eckhardt.de> wrote:
>> > Am 23.10.2012 01:40, schrieb Sarah Sharp:
>> >> On Sun, Oct 21, 2012 at 06:03:24PM +0200, Ulrich Eckhardt wrote:
>> >
>> >>> I have tested it with Kernel 3.6.2. The USB3 port is the one built
>> >>> in the Mainboard M4A87DT EVO.
>> >>
>> >> Did a previous kernel version work?
>> >
>> > Yes, I tried the Kernel shipped with OpenSUSE (3.4.11) several 3.5 and all
>> > available 3.6 kernel versions.
>>
>> I assume you mean that every kernel you tried failed?  If some
>> kernel(s) did work, what is the newest working version and the oldest
>> broken version?
>>
>> > I attach the complete dmesg logs and the lspci -vv output as requested by
>> > Bjorn for the situations when the controller does not work after startup
>> > (extension notworking), when the controller is working (extension OK), and
>> > after stopping (extension stop).
>>
>> In the "notworking" logs, my guess is that the xHCI device is being
>> powered off.  The "notworking" lspci shows this:
>>
>>   00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD790 PCI
>> to PCI bridge (PCI express gpp port F) (prog-if 00 [Normal decode])
>>         Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
>>                 LnkCap: Port #247, Speed 5GT/s, Width x2, ASPM L0s L1,
>> Latency L0 <64ns, L1 <1us
>>                 LnkSta: Speed unknown, Width x1, TrErr- Train-
>> SlotClk+ DLActive- BWMgmt+ ABWMgmt+
>>   04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
>> Controller (rev ff) (prog-if ff)
>>         !!! Unknown header type 7f
>>         Kernel driver in use: xhci_hcd
>>
>> The bridge's "DLActive-" means that the downstream link leading to the
>> xHCI device is not active.  The "rev ff", "prog-if ff", and "header
>> type 7f" suggest that we read all 0xff's from the xHCI device, which
>> is what we get if the device doesn't respond.
>>
>> The xHCI device must have been powered up and working originally,
>> because we enumerated it and bound the xhci_hcd driver to it.  I don't
>> have any ideas about why it would be powered off.
>>
>> Rafael, Alan, is there any way we can disable power management or
>> enable related debug messages?
>
> It can be disabled by writing "on" to the controller's
> /sys/devices/.../power/control file.

Ulrich, if you boot in the working situation and write "on" to the
control file as above, can you still reproduce the failure?

> For debug, there are trace points in rpm_suspend() and rpm_resume().

I don't know how to use those.  Is there a doc somewhere?

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Rafael J. Wysocki]

On Wednesday 24 of October 2012 15:13:45 Bjorn Helgaas wrote:
> On Wed, Oct 24, 2012 at 3:10 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Wednesday 24 of October 2012 14:18:40 Bjorn Helgaas wrote:
> >> On Tue, Oct 23, 2012 at 11:14 AM, Ulrich Eckhardt <usb@uli-eckhardt.de> wrote:
> >> > Am 23.10.2012 01:40, schrieb Sarah Sharp:
> >> >> On Sun, Oct 21, 2012 at 06:03:24PM +0200, Ulrich Eckhardt wrote:
> >> >
> >> >>> I have tested it with Kernel 3.6.2. The USB3 port is the one built
> >> >>> in the Mainboard M4A87DT EVO.
> >> >>
> >> >> Did a previous kernel version work?
> >> >
> >> > Yes, I tried the Kernel shipped with OpenSUSE (3.4.11) several 3.5 and all
> >> > available 3.6 kernel versions.
> >>
> >> I assume you mean that every kernel you tried failed?  If some
> >> kernel(s) did work, what is the newest working version and the oldest
> >> broken version?
> >>
> >> > I attach the complete dmesg logs and the lspci -vv output as requested by
> >> > Bjorn for the situations when the controller does not work after startup
> >> > (extension notworking), when the controller is working (extension OK), and
> >> > after stopping (extension stop).
> >>
> >> In the "notworking" logs, my guess is that the xHCI device is being
> >> powered off.  The "notworking" lspci shows this:
> >>
> >>   00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD790 PCI
> >> to PCI bridge (PCI express gpp port F) (prog-if 00 [Normal decode])
> >>         Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
> >>                 LnkCap: Port #247, Speed 5GT/s, Width x2, ASPM L0s L1,
> >> Latency L0 <64ns, L1 <1us
> >>                 LnkSta: Speed unknown, Width x1, TrErr- Train-
> >> SlotClk+ DLActive- BWMgmt+ ABWMgmt+
> >>   04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
> >> Controller (rev ff) (prog-if ff)
> >>         !!! Unknown header type 7f
> >>         Kernel driver in use: xhci_hcd
> >>
> >> The bridge's "DLActive-" means that the downstream link leading to the
> >> xHCI device is not active.  The "rev ff", "prog-if ff", and "header
> >> type 7f" suggest that we read all 0xff's from the xHCI device, which
> >> is what we get if the device doesn't respond.
> >>
> >> The xHCI device must have been powered up and working originally,
> >> because we enumerated it and bound the xhci_hcd driver to it.  I don't
> >> have any ideas about why it would be powered off.
> >>
> >> Rafael, Alan, is there any way we can disable power management or
> >> enable related debug messages?
> >
> > It can be disabled by writing "on" to the controller's
> > /sys/devices/.../power/control file.
> 
> Ulrich, if you boot in the working situation and write "on" to the
> control file as above, can you still reproduce the failure?
> 
> > For debug, there are trace points in rpm_suspend() and rpm_resume().
> 
> I don't know how to use those.  Is there a doc somewhere?

I'm not sure, but let's ask the developer who added them.

Lei, do you have any doc describing how to use those tracepoints?

Rafael


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

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Ming Lei]

On Thu, Oct 25, 2012 at 5:31 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:

>> I don't know how to use those.  Is there a doc somewhere?
>
> I'm not sure, but let's ask the developer who added them.
>
> Lei, do you have any doc describing how to use those tracepoints?

Hi Bjorn Helgaas,

Firstly, please enable these tracepoints via below

          echo 1 > /sys/kernel/debug/tracing/events/rpm/enable

then store the trace event result by below once you make sure your interested
events are completed:

          echo 0 > /sys/kernel/debug/tracing/events/rpm/enable
          cp /sys/kernel/debug/tracing/trace /media/ram/rpm-trace

For the format of the captured trace log(rpm-trace), please see

                include/trace/events/rpm.h

which is just a replacement of previous printk and add some extra fields
into that.  If you still don't understand the format, please post the
result onto list, and I think many guys here may help you out.

Hope the above can help you.


Thanks,
--
Ming Lei

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Bjorn Helgaas]

On Wed, Oct 24, 2012 at 7:24 PM, Ming Lei <ming.lei@canonical.com> wrote:
> On Thu, Oct 25, 2012 at 5:31 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
>>> I don't know how to use those.  Is there a doc somewhere?
>>
>> I'm not sure, but let's ask the developer who added them.
>>
>> Lei, do you have any doc describing how to use those tracepoints?
>
> Hi Bjorn Helgaas,
>
> Firstly, please enable these tracepoints via below
>
>           echo 1 > /sys/kernel/debug/tracing/events/rpm/enable
>
> then store the trace event result by below once you make sure your interested
> events are completed:
>
>           echo 0 > /sys/kernel/debug/tracing/events/rpm/enable
>           cp /sys/kernel/debug/tracing/trace /media/ram/rpm-trace
>
> For the format of the captured trace log(rpm-trace), please see
>
>                 include/trace/events/rpm.h
>
> which is just a replacement of previous printk and add some extra fields
> into that.  If you still don't understand the format, please post the
> result onto list, and I think many guys here may help you out.
>
> Hope the above can help you.

For the archives, it looks like Documentation/trace/events.txt has a
generic intro to this area.

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Ulrich Eckhardt]

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

Am 25.10.2012 03:24, schrieb Ming Lei:
>> Lei, do you have any doc describing how to use those tracepoints?
>
> Hi Bjorn Helgaas,
>
> Firstly, please enable these tracepoints via below
>
>            echo 1 > /sys/kernel/debug/tracing/events/rpm/enable
>
> then store the trace event result by below once you make sure your interested
> events are completed:
>
>            echo 0 > /sys/kernel/debug/tracing/events/rpm/enable
>            cp /sys/kernel/debug/tracing/trace /media/ram/rpm-trace
>
Hi,

I have created a trace according this description. Therefore I have 
rebooted my system, enabled the trace and inserted and removed the 
SD-card until the controller stops working. During this procedure I 
observed that the controller seems to be more stable. I had to insert 
and remove the SD-card several times until the controller stopped 
working. Normally the controller will fail on the first attempt. Also I 
had the impression (not sure about this since I have not measured it) 
that the card reader reads the data faster.

I append the gzipped trace and the corresponding dmesg output.

Best Regards
Uli
-- 
Ulrich Eckhardt                  http://www.uli-eckhardt.de

Ein Blitzableiter auf dem Kirchturm ist das denkbar stärkste
Misstrauensvotum gegen den lieben Gott. (Karl Krauss)

[-- Attachment #2: trace.txt.gz --]
[-- Type: application/x-gunzip, Size: 6026 bytes --]

[-- Attachment #3: dmesg.txt.gz --]
[-- Type: application/x-gunzip, Size: 16832 bytes --]

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Alan Stern]

On Thu, 25 Oct 2012, Ulrich Eckhardt wrote:

> Am 25.10.2012 03:24, schrieb Ming Lei:
> >> Lei, do you have any doc describing how to use those tracepoints?
> >
> > Hi Bjorn Helgaas,
> >
> > Firstly, please enable these tracepoints via below
> >
> >            echo 1 > /sys/kernel/debug/tracing/events/rpm/enable
> >
> > then store the trace event result by below once you make sure your interested
> > events are completed:
> >
> >            echo 0 > /sys/kernel/debug/tracing/events/rpm/enable
> >            cp /sys/kernel/debug/tracing/trace /media/ram/rpm-trace
> >
> Hi,
> 
> I have created a trace according this description. Therefore I have 
> rebooted my system, enabled the trace and inserted and removed the 
> SD-card until the controller stops working. During this procedure I 
> observed that the controller seems to be more stable. I had to insert 
> and remove the SD-card several times until the controller stopped 
> working. Normally the controller will fail on the first attempt. Also I 
> had the impression (not sure about this since I have not measured it) 
> that the card reader reads the data faster.
> 
> I append the gzipped trace and the corresponding dmesg output.

There's a much more straightforward way of telling when a PCI-based USB 
host controller gets suspended or resumed.  Just enable 
CONFIG_USB_DEBUG; then there will appropriate lines in the dmesg log.

Alan Stern

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Ulrich Eckhardt]

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

Am 25.10.2012 20:19, schrieb Alan Stern:

> There's a much more straightforward way of telling when a PCI-based USB
> host controller gets suspended or resumed.  Just enable
> CONFIG_USB_DEBUG; then there will appropriate lines in the dmesg log.

I have compiled a Kernel 3.6.3 with enabled USB debugging today. The 
dmesg log is attached.

Best Regards
Uli
-- 
Ulrich Eckhardt                  http://www.uli-eckhardt.de

Ein Blitzableiter auf dem Kirchturm ist das denkbar stärkste
Misstrauensvotum gegen den lieben Gott. (Karl Krauss)

[-- Attachment #2: dmsg.txt.gz --]
[-- Type: application/x-gunzip, Size: 24640 bytes --]

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Ulrich Eckhardt]

Am 24.10.2012 23:13, schrieb Bjorn Helgaas:
> On Wed, Oct 24, 2012 at 3:10 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
>> It can be disabled by writing "on" to the controller's
>> /sys/devices/.../power/control file.
>
> Ulrich, if you boot in the working situation and write "on" to the
> control file as above, can you still reproduce the failure?

I have done first a cat to the control file which returns already on:

uli:/ # cat /sys/devices/pci0000\:00/0000\:00\:04.0/power/control
on

Writing again on to the file does not change anything.

Best Regards
Uli
-- 
Ulrich Eckhardt                  http://www.uli-eckhardt.de

Ein Blitzableiter auf dem Kirchturm ist das denkbar stärkste
Misstrauensvotum gegen den lieben Gott. (Karl Krauss)

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Rafael J. Wysocki]

On Thursday, October 25, 2012 07:15:58 PM Ulrich Eckhardt wrote:
> Am 24.10.2012 23:13, schrieb Bjorn Helgaas:
> > On Wed, Oct 24, 2012 at 3:10 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >
> >> It can be disabled by writing "on" to the controller's
> >> /sys/devices/.../power/control file.
> >
> > Ulrich, if you boot in the working situation and write "on" to the
> > control file as above, can you still reproduce the failure?
> 
> I have done first a cat to the control file which returns already on:
> 
> uli:/ # cat /sys/devices/pci0000\:00/0000\:00\:04.0/power/control
> on
> 
> Writing again on to the file does not change anything.

Yes, and this means that runtime PM is disabled on the controller.

ASPM remains as a possible culprit, then.

Can you please boot with pcie_aspm=off in the kernel command line and see
if this makes a difference?

Rafael


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

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Ulrich Eckhardt]

Am 25.10.2012 22:11, schrieb Rafael J. Wysocki:
> On Thursday, October 25, 2012 07:15:58 PM Ulrich Eckhardt wrote:
>> I have done first a cat to the control file which returns already on:
>>
>> uli:/ # cat /sys/devices/pci0000\:00/0000\:00\:04.0/power/control
>> on
>>
>> Writing again on to the file does not change anything.
>
> Yes, and this means that runtime PM is disabled on the controller.
>
> ASPM remains as a possible culprit, then.
>
> Can you please boot with pcie_aspm=off in the kernel command line and see
> if this makes a difference?

It make no difference:
    ...
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: 
root=/dev/disk/by-id/ata-Corsair_Force_3_SSD_123079600000149504CF-part1 
resume=/dev/disk/by-id/ata-WDC_WD20EARX-00PASB0_WD-WCAZA7766668-part2 
splash=silent quiet vga=0x31a pcie_aspm=off
[    0.000000] bootsplash: silent mode.
[    0.000000] PCIe ASPM is disabled
    ...
[  124.949190] sdf: detected capacity change from 2032664576 to 0
[  132.387722] sd 10:0:0:2: [sdf] 3970048 512-byte logical blocks: (2.03 
GB/1.89 GiB)
[  132.388881] sd 10:0:0:2: [sdf] No Caching mode page present
[  132.388891] sd 10:0:0:2: [sdf] Assuming drive cache: write through
[  132.390876] sd 10:0:0:2: [sdf] No Caching mode page present
[  132.390885] sd 10:0:0:2: [sdf] Assuming drive cache: write through
[  132.393259]  sdf: sdf1
[  137.286335] sdf: detected capacity change from 2032664576 to 0
[  144.304194] sd 10:0:0:2: [sdf] 3970048 512-byte logical blocks: (2.03 
GB/1.89 GiB)
[  144.305345] sd 10:0:0:2: [sdf] No Caching mode page present
[  144.305356] sd 10:0:0:2: [sdf] Assuming drive cache: write through
[  144.307389] sd 10:0:0:2: [sdf] No Caching mode page present
[  144.307399] sd 10:0:0:2: [sdf] Assuming drive cache: write through
[  144.309682]  sdf: sdf1
[  217.179499] hub 9-0:1.0: cannot reset port 2 (err = -19)
[  217.440798] hub 9-0:1.0: hub_port_status failed (err = -19)
[  217.440865] sd 10:0:0:2: Device offlined - not ready after error recovery
[  217.440873] sd 10:0:0:2: [sdf] Unhandled error code
[  217.440875] sd 10:0:0:2: [sdf]
[  217.440876] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[  217.440878] sd 10:0:0:2: [sdf] CDB:
[  217.440879] Read(10): 28 00 00 00 0f 00 00 00 f0 00
[  217.440884] end_request: I/O error, dev sdf, sector 3840
[  217.440909] sd 10:0:0:2: rejecting I/O to offline device
[  217.440911] sd 10:0:0:2: killing request
[  217.440945] sd 10:0:0:2: rejecting I/O to offline device
[  217.440958] sd 10:0:0:2: [sdf] killing request
[  217.440968] sd 10:0:0:2: rejecting I/O to offline device
[  217.440977] sd 10:0:0:2: rejecting I/O to offline device
[  217.440979] sd 10:0:0:2: rejecting I/O to offline device
[  217.441003] sd 10:0:0:2: [sdf] Unhandled error code
[  217.441008] sd 10:0:0:2: [sdf]
[  217.441012] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[  217.441017] sd 10:0:0:2: [sdf] CDB:
[  217.441020] Read(10): 28 00 00 00 0f f0 00 00 10 00
[  217.441036] end_request: I/O error, dev sdf, sector 4080
[  217.442200] sd 10:0:0:2: rejecting I/O to offline device
[  217.442252] sd 10:0:0:2: rejecting I/O to offline device

-- 
Ulrich Eckhardt                  http://www.uli-eckhardt.de

Ein Blitzableiter auf dem Kirchturm ist das denkbar stärkste
Misstrauensvotum gegen den lieben Gott. (Karl Krauss)

Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Rafael J. Wysocki]

On Wednesday, October 24, 2012 02:18:40 PM Bjorn Helgaas wrote:
> On Tue, Oct 23, 2012 at 11:14 AM, Ulrich Eckhardt <usb@uli-eckhardt.de> wrote:
> > Am 23.10.2012 01:40, schrieb Sarah Sharp:
> >> On Sun, Oct 21, 2012 at 06:03:24PM +0200, Ulrich Eckhardt wrote:
> >
> >>> I have tested it with Kernel 3.6.2. The USB3 port is the one built
> >>> in the Mainboard M4A87DT EVO.
> >>
> >> Did a previous kernel version work?
> >
> > Yes, I tried the Kernel shipped with OpenSUSE (3.4.11) several 3.5 and all
> > available 3.6 kernel versions.
> 
> I assume you mean that every kernel you tried failed?  If some
> kernel(s) did work, what is the newest working version and the oldest
> broken version?
> 
> > I attach the complete dmesg logs and the lspci -vv output as requested by
> > Bjorn for the situations when the controller does not work after startup
> > (extension notworking), when the controller is working (extension OK), and
> > after stopping (extension stop).
> 
> In the "notworking" logs, my guess is that the xHCI device is being
> powered off.  The "notworking" lspci shows this:
> 
>   00:0a.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI RD790 PCI
> to PCI bridge (PCI express gpp port F) (prog-if 00 [Normal decode])
>         Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
>                 LnkCap: Port #247, Speed 5GT/s, Width x2, ASPM L0s L1,
> Latency L0 <64ns, L1 <1us
>                 LnkSta: Speed unknown, Width x1, TrErr- Train-
> SlotClk+ DLActive- BWMgmt+ ABWMgmt+
>   04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host
> Controller (rev ff) (prog-if ff)
>         !!! Unknown header type 7f
>         Kernel driver in use: xhci_hcd
> 
> The bridge's "DLActive-" means that the downstream link leading to the
> xHCI device is not active.  The "rev ff", "prog-if ff", and "header
> type 7f" suggest that we read all 0xff's from the xHCI device, which
> is what we get if the device doesn't respond.

Can it be an ASPM issue?

Rafael


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