Re: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

["Rafael J. Wysocki" <rjw@sisk.pl>]

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.