At Fri, 18 Feb 2011 08:15:25 +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. > > > > > > > > I tested with two USB audio 1.x devices, and both show the similar > > > > behavior. > > > > > > > > Can this be a better hint for further looking? > > > > Maybe. I've got a couple patches in my queue that I need to send to > > Greg that involve fixes in the ring TRB counting calculation. Can you > > reset against my for-usb-linus-pending branch in the xhci.git tree on > > kernel.org and see if those patches fix your issue? > > I'm off today, so will check it on the next Monday (the machine is > in office). It doesn't fix, unfortunately. No change in the behavior at probing. thanks, Takashi -- 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
