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. A third hypothesis is that there's a race condition between the end of the xHCI URB cancellation process and switching alternate interface settings. I think the xHCI driver could basically tear down the endpoint structures before the Set TR Dequeue Pointer command for that endpoint's ring pointer finishes. That means we could call ring_doorbell_for_active_rings() on an endpoint that has just been removed. I'll have to look at the cancellation code. Alt setting changes can also race with resetting endpoints, so handle_reset_ep_completion() could call ring_doorbell_for_active_rings() with an inactive ring. I would really expect the driver to actually wait on the reset endpoint call into the USB core to finish before switching alt settings though. That Fresco Logic chip also has the XHCI_RESET_EP_QUIRK, which means that we have to ring the doorbells after every Configure Endpoint command. That shouldn't be a big problem though. I suppose the quick fix is just to handle the NULL pointer in ring_doorbell_for_active_rings(), but I would like to know *why* it's being called with a NULL pointer. 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
