* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader [not found] <20121126191002.GE6504@xanatos> @ 2012-11-26 21:48 ` Bjørn Mork 2012-11-28 22:54 ` Sarah Sharp 0 siblings, 1 reply; 28+ messages in thread From: Bjørn Mork @ 2012-11-26 21:48 UTC (permalink / raw) To: Sarah Sharp Cc: Ulrich Eckhardt, Andrew Lutomirski, linux-usb, Alan Stern, Ming Lei, Rafael J. Wysocki, Bjorn Helgaas, linux-pci, Huang Ying 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-11-26 21:48 ` Unreliable USB3 with NEC uPD720200 and Delock Cardreader Bjørn Mork @ 2012-11-28 22:54 ` Sarah Sharp 2012-12-06 0:33 ` Sarah Sharp 0 siblings, 1 reply; 28+ messages in thread From: Sarah Sharp @ 2012-11-28 22:54 UTC (permalink / raw) To: Bjørn Mork Cc: Ulrich Eckhardt, Andrew Lutomirski, linux-usb, Alan Stern, Ming Lei, Rafael J. Wysocki, Bjorn Helgaas, linux-pci, Huang Ying 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-11-28 22:54 ` Sarah Sharp @ 2012-12-06 0:33 ` Sarah Sharp 2012-12-06 0:43 ` Rafael J. Wysocki 2012-12-06 7:17 ` Huang Ying 0 siblings, 2 replies; 28+ messages in thread From: Sarah Sharp @ 2012-12-06 0:33 UTC (permalink / raw) To: Bjørn Mork Cc: Ulrich Eckhardt, Andrew Lutomirski, linux-usb, Alan Stern, Ming Lei, Rafael J. Wysocki, Bjorn Helgaas, linux-pci, Huang Ying 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-12-06 0:33 ` Sarah Sharp @ 2012-12-06 0:43 ` Rafael J. Wysocki 2012-12-07 0:28 ` Sarah Sharp 2012-12-06 7:17 ` Huang Ying 1 sibling, 1 reply; 28+ messages in thread From: Rafael J. Wysocki @ 2012-12-06 0:43 UTC (permalink / raw) To: Sarah Sharp Cc: Bjørn Mork, Ulrich Eckhardt, Andrew Lutomirski, linux-usb, Alan Stern, Ming Lei, Bjorn Helgaas, linux-pci, Huang Ying 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-12-06 0:43 ` Rafael J. Wysocki @ 2012-12-07 0:28 ` Sarah Sharp 2012-12-07 21:00 ` Rafael J. Wysocki 0 siblings, 1 reply; 28+ messages in thread From: Sarah Sharp @ 2012-12-07 0:28 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Bjørn Mork, Ulrich Eckhardt, Andrew Lutomirski, linux-usb, Alan Stern, Ming Lei, Bjorn Helgaas, linux-pci, Huang Ying 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-12-07 0:28 ` Sarah Sharp @ 2012-12-07 21:00 ` Rafael J. Wysocki 2012-12-12 2:32 ` Huang Ying 0 siblings, 1 reply; 28+ messages in thread From: Rafael J. Wysocki @ 2012-12-07 21:00 UTC (permalink / raw) To: Sarah Sharp Cc: Bjørn Mork, Ulrich Eckhardt, Andrew Lutomirski, linux-usb, Alan Stern, Ming Lei, Bjorn Helgaas, linux-pci, Huang Ying 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-12-07 21:00 ` Rafael J. Wysocki @ 2012-12-12 2:32 ` Huang Ying 2012-12-12 2:34 ` Andrew Lutomirski 2012-12-13 19:53 ` Sarah Sharp 0 siblings, 2 replies; 28+ messages in thread From: Huang Ying @ 2012-12-12 2:32 UTC (permalink / raw) To: Rafael J. Wysocki, Sarah Sharp, Andrew Lutomirski, Ulrich Eckhardt Cc: Bjørn Mork, linux-usb, Alan Stern, Ming Lei, Bjorn Helgaas, linux-pci [-- 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-12-12 2:32 ` Huang Ying @ 2012-12-12 2:34 ` Andrew Lutomirski 2012-12-12 3:18 ` huang ying 2012-12-13 19:53 ` Sarah Sharp 1 sibling, 1 reply; 28+ messages in thread From: Andrew Lutomirski @ 2012-12-12 2:34 UTC (permalink / raw) To: Huang Ying Cc: Rafael J. Wysocki, Sarah Sharp, Ulrich Eckhardt, Bjørn Mork, linux-usb, Alan Stern, Ming Lei, Bjorn Helgaas, linux-pci 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 > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-12-12 2:34 ` Andrew Lutomirski @ 2012-12-12 3:18 ` huang ying 0 siblings, 0 replies; 28+ messages in thread From: huang ying @ 2012-12-12 3:18 UTC (permalink / raw) To: Andrew Lutomirski Cc: Huang Ying, Rafael J. Wysocki, Sarah Sharp, Ulrich Eckhardt, Bjørn Mork, linux-usb, Alan Stern, Ming Lei, Bjorn Helgaas, linux-pci 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-12-12 2:32 ` Huang Ying 2012-12-12 2:34 ` Andrew Lutomirski @ 2012-12-13 19:53 ` Sarah Sharp 1 sibling, 0 replies; 28+ messages in thread From: Sarah Sharp @ 2012-12-13 19:53 UTC (permalink / raw) To: Huang Ying Cc: Rafael J. Wysocki, Andrew Lutomirski, Ulrich Eckhardt, Bjørn Mork, linux-usb, Alan Stern, Ming Lei, Bjorn Helgaas, linux-pci 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-12-06 0:33 ` Sarah Sharp 2012-12-06 0:43 ` Rafael J. Wysocki @ 2012-12-06 7:17 ` Huang Ying 2012-12-06 12:43 ` Rafael J. Wysocki 1 sibling, 1 reply; 28+ messages in thread From: Huang Ying @ 2012-12-06 7:17 UTC (permalink / raw) To: Sarah Sharp Cc: Bjørn Mork, Ulrich Eckhardt, Andrew Lutomirski, linux-usb, Alan Stern, Ming Lei, Rafael J. Wysocki, Bjorn Helgaas, linux-pci [-- 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; ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-12-06 7:17 ` Huang Ying @ 2012-12-06 12:43 ` Rafael J. Wysocki 0 siblings, 0 replies; 28+ messages in thread From: Rafael J. Wysocki @ 2012-12-06 12:43 UTC (permalink / raw) To: Huang Ying Cc: Sarah Sharp, Bjørn Mork, Ulrich Eckhardt, Andrew Lutomirski, linux-usb, Alan Stern, Ming Lei, Bjorn Helgaas, linux-pci, Linux PM list 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <50841CCC.9030809@uli-eckhardt.de>]
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader [not found] <50841CCC.9030809@uli-eckhardt.de> @ 2012-10-22 23:40 ` Sarah Sharp 2012-10-23 13:54 ` Bjorn Helgaas 2012-10-23 17:14 ` Ulrich Eckhardt 0 siblings, 2 replies; 28+ messages in thread From: Sarah Sharp @ 2012-10-22 23:40 UTC (permalink / raw) To: Ulrich Eckhardt; +Cc: linux-usb, linux-pci, Bjorn Helgaas 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-22 23:40 ` Sarah Sharp @ 2012-10-23 13:54 ` Bjorn Helgaas 2012-10-23 17:14 ` Ulrich Eckhardt 1 sibling, 0 replies; 28+ messages in thread From: Bjorn Helgaas @ 2012-10-23 13:54 UTC (permalink / raw) To: Sarah Sharp; +Cc: Ulrich Eckhardt, linux-usb, linux-pci 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-22 23:40 ` Sarah Sharp 2012-10-23 13:54 ` Bjorn Helgaas @ 2012-10-23 17:14 ` Ulrich Eckhardt 2012-10-24 20:18 ` Bjorn Helgaas 1 sibling, 1 reply; 28+ messages in thread From: Ulrich Eckhardt @ 2012-10-23 17:14 UTC (permalink / raw) To: linux-usb; +Cc: Sarah Sharp, linux-pci, Bjorn Helgaas [-- 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 --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-23 17:14 ` Ulrich Eckhardt @ 2012-10-24 20:18 ` Bjorn Helgaas 2012-10-24 21:10 ` Rafael J. Wysocki 2012-10-25 20:09 ` Rafael J. Wysocki 0 siblings, 2 replies; 28+ messages in thread From: Bjorn Helgaas @ 2012-10-24 20:18 UTC (permalink / raw) To: Ulrich Eckhardt Cc: linux-usb, Sarah Sharp, linux-pci, Alan Stern, Rafael J. Wysocki 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-24 20:18 ` Bjorn Helgaas @ 2012-10-24 21:10 ` Rafael J. Wysocki 2012-10-24 21:13 ` Bjorn Helgaas 2012-10-25 20:09 ` Rafael J. Wysocki 1 sibling, 1 reply; 28+ messages in thread From: Rafael J. Wysocki @ 2012-10-24 21:10 UTC (permalink / raw) To: Bjorn Helgaas Cc: Ulrich Eckhardt, linux-usb, Sarah Sharp, linux-pci, Alan Stern 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-24 21:10 ` Rafael J. Wysocki @ 2012-10-24 21:13 ` Bjorn Helgaas 2012-10-24 21:31 ` Rafael J. Wysocki 2012-10-25 17:15 ` Ulrich Eckhardt 0 siblings, 2 replies; 28+ messages in thread From: Bjorn Helgaas @ 2012-10-24 21:13 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Ulrich Eckhardt, linux-usb, Sarah Sharp, linux-pci, Alan Stern 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? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-24 21:13 ` Bjorn Helgaas @ 2012-10-24 21:31 ` Rafael J. Wysocki 2012-10-25 1:24 ` Ming Lei 2012-10-25 17:15 ` Ulrich Eckhardt 1 sibling, 1 reply; 28+ messages in thread From: Rafael J. Wysocki @ 2012-10-24 21:31 UTC (permalink / raw) To: Bjorn Helgaas, Ming Lei Cc: Ulrich Eckhardt, linux-usb, Sarah Sharp, linux-pci, Alan Stern 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-24 21:31 ` Rafael J. Wysocki @ 2012-10-25 1:24 ` Ming Lei 2012-10-25 13:33 ` Bjorn Helgaas 2012-10-25 17:43 ` Ulrich Eckhardt 0 siblings, 2 replies; 28+ messages in thread From: Ming Lei @ 2012-10-25 1:24 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Bjorn Helgaas, Ulrich Eckhardt, linux-usb, Sarah Sharp, linux-pci, Alan Stern 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-25 1:24 ` Ming Lei @ 2012-10-25 13:33 ` Bjorn Helgaas 2012-10-25 17:43 ` Ulrich Eckhardt 1 sibling, 0 replies; 28+ messages in thread From: Bjorn Helgaas @ 2012-10-25 13:33 UTC (permalink / raw) To: Ming Lei Cc: Rafael J. Wysocki, Ulrich Eckhardt, linux-usb, Sarah Sharp, linux-pci, Alan Stern 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-25 1:24 ` Ming Lei 2012-10-25 13:33 ` Bjorn Helgaas @ 2012-10-25 17:43 ` Ulrich Eckhardt 2012-10-25 18:19 ` Alan Stern 1 sibling, 1 reply; 28+ messages in thread From: Ulrich Eckhardt @ 2012-10-25 17:43 UTC (permalink / raw) To: linux-usb Cc: Ming Lei, Rafael J. Wysocki, Bjorn Helgaas, Sarah Sharp, linux-pci, Alan Stern [-- 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 --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-25 17:43 ` Ulrich Eckhardt @ 2012-10-25 18:19 ` Alan Stern 2012-10-27 13:02 ` Ulrich Eckhardt 0 siblings, 1 reply; 28+ messages in thread From: Alan Stern @ 2012-10-25 18:19 UTC (permalink / raw) To: Ulrich Eckhardt Cc: linux-usb, Ming Lei, Rafael J. Wysocki, Bjorn Helgaas, Sarah Sharp, linux-pci 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-25 18:19 ` Alan Stern @ 2012-10-27 13:02 ` Ulrich Eckhardt 0 siblings, 0 replies; 28+ messages in thread From: Ulrich Eckhardt @ 2012-10-27 13:02 UTC (permalink / raw) To: linux-usb Cc: Alan Stern, Ming Lei, Rafael J. Wysocki, Bjorn Helgaas, Sarah Sharp, linux-pci [-- 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 --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-24 21:13 ` Bjorn Helgaas 2012-10-24 21:31 ` Rafael J. Wysocki @ 2012-10-25 17:15 ` Ulrich Eckhardt 2012-10-25 20:11 ` Rafael J. Wysocki 1 sibling, 1 reply; 28+ messages in thread From: Ulrich Eckhardt @ 2012-10-25 17:15 UTC (permalink / raw) To: Bjorn Helgaas, linux-usb Cc: Rafael J. Wysocki, Sarah Sharp, linux-pci, Alan Stern 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) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-25 17:15 ` Ulrich Eckhardt @ 2012-10-25 20:11 ` Rafael J. Wysocki 2012-10-26 16:41 ` Ulrich Eckhardt 0 siblings, 1 reply; 28+ messages in thread From: Rafael J. Wysocki @ 2012-10-25 20:11 UTC (permalink / raw) To: Ulrich Eckhardt Cc: Bjorn Helgaas, linux-usb, Sarah Sharp, linux-pci, Alan Stern 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-25 20:11 ` Rafael J. Wysocki @ 2012-10-26 16:41 ` Ulrich Eckhardt 0 siblings, 0 replies; 28+ messages in thread From: Ulrich Eckhardt @ 2012-10-26 16:41 UTC (permalink / raw) To: Rafael J. Wysocki, linux-usb Cc: Bjorn Helgaas, Sarah Sharp, linux-pci, Alan Stern 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) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader 2012-10-24 20:18 ` Bjorn Helgaas 2012-10-24 21:10 ` Rafael J. Wysocki @ 2012-10-25 20:09 ` Rafael J. Wysocki 1 sibling, 0 replies; 28+ messages in thread From: Rafael J. Wysocki @ 2012-10-25 20:09 UTC (permalink / raw) To: Bjorn Helgaas Cc: Ulrich Eckhardt, linux-usb, Sarah Sharp, linux-pci, Alan Stern 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2012-12-13 19:53 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20121126191002.GE6504@xanatos> 2012-11-26 21:48 ` Unreliable USB3 with NEC uPD720200 and Delock Cardreader Bjørn Mork 2012-11-28 22:54 ` Sarah Sharp 2012-12-06 0:33 ` Sarah Sharp 2012-12-06 0:43 ` Rafael J. Wysocki 2012-12-07 0:28 ` Sarah Sharp 2012-12-07 21:00 ` Rafael J. Wysocki 2012-12-12 2:32 ` Huang Ying 2012-12-12 2:34 ` Andrew Lutomirski 2012-12-12 3:18 ` huang ying 2012-12-13 19:53 ` Sarah Sharp 2012-12-06 7:17 ` Huang Ying 2012-12-06 12:43 ` Rafael J. Wysocki [not found] <50841CCC.9030809@uli-eckhardt.de> 2012-10-22 23:40 ` Sarah Sharp 2012-10-23 13:54 ` Bjorn Helgaas 2012-10-23 17:14 ` Ulrich Eckhardt 2012-10-24 20:18 ` Bjorn Helgaas 2012-10-24 21:10 ` Rafael J. Wysocki 2012-10-24 21:13 ` Bjorn Helgaas 2012-10-24 21:31 ` Rafael J. Wysocki 2012-10-25 1:24 ` Ming Lei 2012-10-25 13:33 ` Bjorn Helgaas 2012-10-25 17:43 ` Ulrich Eckhardt 2012-10-25 18:19 ` Alan Stern 2012-10-27 13:02 ` Ulrich Eckhardt 2012-10-25 17:15 ` Ulrich Eckhardt 2012-10-25 20:11 ` Rafael J. Wysocki 2012-10-26 16:41 ` Ulrich Eckhardt 2012-10-25 20:09 ` Rafael J. Wysocki
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.