On Tue, 6 Dec 2011 12:07:20 -0800 Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > The babble > could have been caused by the device, but it also could have been > caused by a bad cable as well. Have you tried swapping the cable or > UAS device? > The bug reporters all say that blacklisting the uas driver makes everything work, so I doubt it's the cables. Though one of them keeps getting this over and over even though the device works: xhci_hcd 0000:02:00.0: WARN: Stalled endpoint > The last two lines are a bit odd though. They indicate the xHCI host > didn't like the xHCI driver trying to move the dequeue pointer past > the transfer that caused the babble. That shouldn't have been an > issue. Getting a transfer event for an incorrect stream ring is also > troubling. > > What xHCI host are you plugging the UAS device into? Can you send the > lspci -vvv output? > 02:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) (prog-if 30 [XHCI]) Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 17 Region 0: Memory at fe6fe000 (64-bit, non-prefetchable) [size=8K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [90] MSI-X: Enable+ Count=8 Masked- Vector table: BAR=0 offset=00001000 PBA: BAR=0 offset=00001080 Capabilities: [a0] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend- LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 unlimited ClockPM+ Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis+ DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -3.5dB Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn- Capabilities: [140 v1] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff Capabilities: [150 v1] #18 Kernel driver in use: xhci_hcd > > xhci_hcd 0000:04:00.0: xHCI xhci_drop_endpoint called with disabled > > ep ffff880113706dc0 Jun 29 09:52:11 karryall kernel: [ 302.094253] > > xhci_hcd 0000:04:00.0: WARN no SS endpoint bMaxBurst > > That's odd. Does your Fedora kernel have this patch in it? > > commit d23336329fa4c157ed6256d4279a73b87486a1b6 > Author: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> > Date: Mon Jun 6 00:53:47 2011 -0700 > > xhci: Don't warn about zeroed bMaxBurst descriptor field. That went in 3.0-rc6 and we're on 3.1.1, so we do have it. > And then the UAS driver doesn't recover from the device reset. It's > not surprising to me. The UAS driver is still experimental, and it > just doesn't have good error handling. I think we're going to disable the driver for now, at least for production kernels. -- 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
