Hi Thilo, looking into your previous lspci posts I see you might be affected by this hardware bug in "Intel® 6 Series Express Chipset B2 stepping" chips having enabled SATA ports 2-5. http://support.dell.com/support/topics/global.aspx/support/kcs/document?c=us&cs=04&docid=389728&l=en&s=bsd http://www.intel.com/support/chipsets/6/sb/CS-032521.htm http://www.intel.com/support/chipsets/6/sb/CS-032521.htm Second, just few days ago we sorted out on linux-pci that my Express Card chipset does not report properly express card removal from the slot. (thread Re: 3.2.11: PCI Express card cannot be re-detected withing cca 60sec timeframe) Interestingly, and that is why I am writing this email, it happens to me *only* with express card having uPD720200 as well (but I have 3028 firmware, the latest of the 3.x series because I have older harware). My express card slot chipset properly reports when I unplug a FireWire express card or one providing 2 serial and 1 parallel port. I do not know what is different with the NEC-based card. I can only say that USB3.0 throughput is 80MB/s while under Win 7 I get 146 MB/s using same hardware. Back to Linux, an onboard Texas INstruments chipset providing USB 3.0 as well also give sme 146 MB/s, so there is not a problem with xhci_hcd but with pci express chipset, DMA?, or its linux driver making it slow. Finally, you can upgrade your NEC firmware with the tools and image from http://www.station-drivers.com/page/renesas.htm . Pickup some of those 4.x firmwares and don't use the GUI, use the command line to determine your flash chipset before doing backup and re-flashing. Best, Martin Xu, Andiry wrote: > Sorry for the top-posting. > > I don't know what causes freeze - and NEC uPD720200 should work fine with suspend. > Usually if the host suspend fail, the system should abort suspend and back into running state. > You can try unload xhci-hcd before suspend and load it after resume. It should work. > Before xHCI suspend/resume is supported in 2.6.37, distrtibutions enter suspend use this way. > > Thanks, > Andiry > ________________________________________ > From: Thilo-Alexander Ginkel [thilo@xxxxxxxxxx] > Sent: Tuesday, April 17, 2012 12:54 AM > To: Xu, Andiry > Cc: Sarah Sharp; linux-usb@xxxxxxxxxxxxxxx > Subject: Re: USB timeout during S3 suspend w/ NEC Corporation uPD720200 > > On Tue, Mar 20, 2012 at 13:55, Thilo-Alexander Ginkel <thilo@xxxxxxxxxx> wrote: >> On Tue, Mar 13, 2012 at 02:18, Xu, Andiry <Andiry.Xu@xxxxxxx> wrote: >>>> It doesn't necessarily mean that the host got removed. When the PCI >>>> host controller goes into D3, the registers will read as 0xffffffff. So >>>> I suspect the host was just suspended when the polling loop ran. We >>>> need a better way for the polling loop to know the host controller died >>>> instead of checking the registers. >>> >>> I agree with you, but for this case, the suspend is actually failed: >>> Stop xHC in xhci_suspend() timeout and the function returns -110. >>> The save state register is not set. I think the PCI host controller >>> does not go into D3 in this case, right? >> >> P.S.: Just updated to 3.3 - I'll keep you updated whether the freezes >> are still an issue... > > Just had another freeze while running > > Linux orion 3.3.1 #30 SMP Mon Apr 2 23:33:43 CEST 2012 x86_64 x86_64 > x86_64 GNU/Linux > > Same symptoms, i.e., suspending fails with return code -110. > > Do you have an idea what actually causes the freeze? Does the kernel > wait until all devices are suspended (in my case infinitely)? > > Would it be possible to work around the issue be letting the system > enter S3 anyway and reinitialize the USB controller on resume? Can I > force this by unloading the xhci module? > > Thanks for your help! > > Regards, > Thilo > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
