At Wed, 20 Jun 2012 11:36:36 -0700, Sarah Sharp wrote: > > On Wed, Jun 20, 2012 at 02:49:10PM -0300, Sergio Correia wrote: > > Sarah, I also see messages like these on the dmesg output: > > > > input: Sony Computer Entertainment Wireless Stereo Headset as > > /devices/pci0000:00/0000:00:1c.3/0000:04:00.0/usb3/3-1/3-1:1.3/input/input10 > > hid-generic 0003:12BA:0030.0005: input,hiddev0,hidraw2: USB HID v1.01 > > Device [Sony Computer Entertainment Wireless Stereo Headset > > usbcore: registered new interface driver snd-usb-audio > > xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or > > incorrect stream ring > > xhci_hcd 0000:04:00.0: @00000000a683f620 9ed7c580 00000000 1a000000 02058001 > > xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or > > incorrect stream ring > > xhci_hcd 0000:04:00.0: @00000000a683f6b0 9ed7caa0 00000000 1a000000 02058001 > > sock: process `skype' is using obsolete setsockopt SO_BSDCOMPAT > > xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or > > incorrect stream ring > > xhci_hcd 0000:04:00.0: @00000000a683f450 a6932410 00000000 1a000000 02058000 > > xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or > > incorrect stream ring > > xhci_hcd 0000:04:00.0: @00000000a683f600 a6854580 00000000 1a000000 02058000 > > xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or > > incorrect stream ring > > xhci_hcd 0000:04:00.0: @00000000a683f550 a6854810 00000000 1a000000 02058001 > > xhci_hcd 0000:04:00.0: WARN Set TR Deq Ptr cmd failed due to > > incorrect slot or ep state. > > Yeah, those are pretty bad messages. They mean the host controller is > giving us transfers for an endpoint that hasn't been configured through > a usb_set_interface() call (or was removed in a call to > usb_set_interface()). > > Can you recompile your kernel with CONFIG_USB_DEBUG and > CONFIG_USB_XHCI_HCD_DEBUGGING turned on, and then use netconsole to > capture the oops? I need more info about what endpoints were set up at > the time. > > My first hypothesis is the xHCI hardware is broken (highly > likely, since it's a Fresco Logic chip and those have a lot of quirks). > > A second hypothesis is that the USB sound driver is switching alt > settings without bothering to wait until all the URBs for the old alt > setting complete or are canceled. That will probably work under EHCI, > but that won't work under xHCI because we need to tear down internal > structures whenever a new alt setting is installed. That doesn't > look to be the case from a quick glance at the commit ID though. > > Takashi, can you explain what new functionality was added in that patch? > I'm not very familiar with the sound stack, but maybe if you explained > what the code is trying to do on the USB level that would help. The specific commit Sergio reached via bisection is for changing the assignment of endpoint with sync or not. The oneliner below should disable the change effectively. If this fixes the problem, we need to take a deeper look at the code there. Before that commit, there are a series of commits to change the endpoint handling logic. But judging from the bisection, this shouldn't be the issue... Takashi --- diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 54607f8..9cbf9ea 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -376,6 +376,7 @@ static int set_format(struct snd_usb_substream *subs, struct audioformat *fmt) == USB_ENDPOINT_USAGE_IMPLICIT_FB; add_sync_ep: + implicit_fb = 0; /* XXX */ subs->sync_endpoint = snd_usb_add_endpoint(subs->stream->chip, alts, ep, !subs->direction, implicit_fb ? -- 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
