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@xxxxxxx> 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@xxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
