On Mon, Feb 21, 2011 at 03:56:52PM +0100, Takashi Iwai wrote: > At Mon, 21 Feb 2011 06:47:20 -0800, > Sarah Sharp wrote: > > > > 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. Ah, ok, makes sense. > > 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. >From your roothub descriptors, it looks like you're running 2.6.32.27? The 2.6.32 stable kernel doesn't include support for isochronous transfers, because it was such a large feature that we didn't want to backport it. In fact, I'm not even sure 2.6.32 had stall support, or support for setting alternate interface settings, since those both required API changes to the USB core. Can you try 2.6.37 instead? 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
