At Mon, 21 Feb 2011 06:47:20 -0800, Sarah Sharp wrote: > > On Fri, Feb 18, 2011 at 08:15:25AM +0100, Takashi Iwai wrote: > > At Thu, 17 Feb 2011 12:23:43 -0800, > > Sarah Sharp wrote: > > > > > > On Thu, Feb 17, 2011 at 04:53:41PM +0100, Takashi Iwai wrote: > > > > At Thu, 17 Feb 2011 16:43:28 +0100, > > > > Takashi Iwai wrote: > > > > > > > > > > [OK, moved now to linux-usb ML...] > > > > > > > > > > At Fri, 11 Feb 2011 10:44:57 -0800, > > > > > Sarah Sharp wrote: > > > > > > > > > > > > On Fri, Feb 11, 2011 at 11:11:29AM +0100, Takashi Iwai wrote: > > > > > > > Actually the audio on xhci seems broken, so far. > > > > > > > Recently I tested usb audio devices with xhci on new HP laptops, and > > > > > > > got several different errors per kernel versions. > > > > > > > > > > > > I would be interested if you could send those errors to the linux-usb > > > > > > mailing list and Cc me. > > > > > > > > > > > > > I had no time to dig into the issue yet, but if it's related with > > > > > > > bandwidth setup, we'd need definitely to work on it together. > > > > > > > > > > > > The HP laptops have an NEC host controller in them, and I have heard > > > > > > some complaints about their isoc support. They do have a firmware update > > > > > > that improves that support, so you may want to google around for that. > > > > > > > > > > > > The other issue is the xHCI driver design. Currently, with 0.96 xHCI > > > > > > hardware, we get multiple interrupts per isoc URB (as many interrupts as > > > > > > there are isoc buffers). I have a work around in mind, but it involves > > > > > > updating the xHCI ring code, which is always somewhat hairy and may take > > > > > > a month or so. However, for xHCI 1.0 host controllers, the spec > > > > > > architects have made some improvements that will easily allow us to get > > > > > > less interrupts (once per URB, or even less if the driver submits > > > > > > several URBs and marks some of them with the URB_NO_INTERRUPT flag). > > > > > > That only involves setting one bit, so that would be an easy one day > > > > > > fix. > > > > > > > > > > > > Then there's the fact that the xHCI driver's ring code is recursive. :( > > > > > > I wrote it at 3 in the morning a couple days before a demo, and I really > > > > > > need to fix that ASAP. There's also still performance issues, like > > > > > > register reads in the interrupt path that really should be removed. > > > > > > > > > > > > But we should really pull in the linux-usb mailing list into any further > > > > > > discussion of this. :) > > > > > > > > > > Looking down more at the errors, it seems that the controller stalls > > > > > after some point. First, "short transfer on control ep" comes up once > > > > > or twice: > > > > > > > > > > [ 1391.490134] xhci_hcd 0000:27:00.0: WARN: short transfer on control ep > > > > > [ 1391.479142] xhci_hcd 0000:27:00.0: WARN: short transfer on control ep > > > > > > > > > > Then it starts "Stalled endpoint": > > > > > > > > > > [ 1391.498122] xhci_hcd 0000:27:00.0: WARN: Stalled endpoint > > > > > [ 1391.505114] xhci_hcd 0000:27:00.0: WARN: Stalled endpoint > > > > > [ 1391.512114] xhci_hcd 0000:27:00.0: WARN: Stalled endpoint > > > > > ... > > > > > > > > > > At each time a stall happens, 3 trbs are queued up and pending. So, > > > > > after repeating this cycle, it finally reaches to "no room": > > > > > > > > > > [ 1401.120101] xhci_hcd 0000:27:00.0: ERROR no room on ep ring > > > > > > > > > > The behavior looks consistent no matter which kernel version is used > > > > > between 2.6.32 and 2.6.38-rc5. So, the problem is before isoc things, > > > > > but in other points. > > > > > > > > > > FWIW, the ring causing this error is no ctrl but slot 1 ep 0. > > Are you saying that the endpoint that is stalling is not a control > endpoint, but it is advertised with an endpoint address of zero? I > can't figure out what "no ctrl" means. :) Sorry for unclearness. I meant as cmd_ring instead ctrl. The affected ring is associated with slot 1 ep0 (judging from my debug code), neither event_ring nor cmd_ring. > I was wondering what type of endpoint was stalling, since the USB audio > devices I have advertises one isochronous endpoint. Isochronous > endpoints aren't supposed to stall, although I know there was a > clarification to the xHCI 1.0 spec to say that xHCI hosts weren't > supposed to stall an isoc endpoint, so there may be some buggy 0.96 xHCI > hosts that do stall an isoc endpoint. It has mixer controls? The error seems happening before actually handling isoc ep. It's during parsing interfaces and parsing the mixer topology, etc, in usb-audio driver. > Can you give me the lsusb for your device? I'll try to get a patch for > the stall dequeue updates to you this morning. OK, attached below. thanks, Takashi
Attachment:
lsusb.out
Description: Binary data
