On Wed, Dec 07, 2011 at 09:25:46AM -0500, Chuck Ebbert wrote: > 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. Ok, the UAS driver just isn't handling the babble then. > 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 message is harmless. I have a patch to remove it that I haven't submitted to Greg yet. > > 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. Yeah, I don't blame you. Most UAS devices should have Bulk-only-Transport (BoT) as a backup on some interface, so the usb-storage driver will claim it. If the device doesn't have BoT, then it just won't work. But it's probably better to have a stable working driver and some unusable devices than a driver with virtually no error handling. Once I get the UAS driver error handling paths up to snuff, we'll probably handle the usb-storage and uas driver load race by making the usb-storage driver fail a probe of any storage device with a UAS interface. Then the UAS driver will always load for devices that do handle it. Only after the driver gets more stable, of course. Sarah Sharp -- 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
