On Fri, Jan 20, 2012 at 03:16:31PM -0800, Paul Zimmerman wrote: > On 01/18/2012 07:01 AM, Sarah Sharp wrote: > > > The USB 3.0 card reader I have will stall every SCSI command while it is > > empty, so it was only a matter of time before a TD was queued just > > before the link TRB. That's why my box would always hang with the ring > > expansion patchset and that device. > > < snip patch > > > Hi Sarah, > > While running your andiry-ring-expansion branch from today, I got the panic in > the following screenshot: http://i44.tinypic.com/otkbco.jpg Interesting. It seems like it oopsed somewhere in URB completion, and then oopsed again on resubmit. What does running gdb's "l * xhci_urb_enqueue + 0x39e" command look like to you? It looks like it's fetching the input context for me: (gdb) l * (xhci_urb_enqueue + 0x39e) 0x361e is in xhci_urb_enqueue (drivers/usb/host/xhci.c:1062). 1057 1058 /* Set up the input context flags for the command */ 1059 /* FIXME: This won't work if a non-default control endpoint 1060 * changes max packet sizes. 1061 */ 1062 ctrl_ctx = xhci_get_input_control_ctx(xhci, in_ctx); 1063 ctrl_ctx->add_flags = cpu_to_le32(EP0_FLAG); 1064 ctrl_ctx->drop_flags = 0; 1065 1066 xhci_dbg(xhci, "Slot %d input context\n", slot_id); (gdb) > Unfortunately the first dump has scrolled partway offscreen, but the second > dump seems similar, so maybe it will have the same info. Maybe. Or maybe the xHCI driver is feeding a bad URB pointer back to the completion function, which is happily resubmitting it. > I don't know if this is related to this particular patch or not. > > This happened while I was testing a device with the g_zero gadget using the > testusb program on the host. It happened when I tried to run test 10. Without > the ring expansion patches, test 10 always gave an allocation failure when I > tried to run it. Ok, an easy way to see if it is the dynamic ring expansion patches that are causing your oops is to revert the patches, then change the number of ring segments allocated in xhci-mem.c: /* * Isochronous endpoint ring needs bigger size because one isoc URB * carries multiple packets and it will insert multiple tds to the * ring. * This should be replaced with dynamic ring resizing in the future. */ if (usb_endpoint_xfer_isoc(&ep->desc)) virt_dev->eps[ep_index].new_ring = xhci_ring_alloc(xhci, 8, true, true, mem_flags); else virt_dev->eps[ep_index].new_ring = xhci_ring_alloc(xhci, 1, true, false, mem_flags); Change the second parameter to xhci_ring_alloc() to something large enough that you don't get allocation failures. Say 64 segments? > I'm don't know how reproducible this is. I rebooted and ran test 10 again, and > that time there was no panic. There was a different problem, the test hung, so > I am looking at that now. Hmm, is there any way you can run netconsole with xHCI debugging turned on and capture the oops or hang? Thanks for testing the ring expansion patches. 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
