On Tue, Nov 09, 2010 at 02:34:53PM -0800, Paul Zimmerman wrote: > Hi Sarah, > > I am running a modified version of the xhci debugging patch you created for me > a couple of months ago, on top of the 2.6.36 kernel. I hit the second WARN in > xhci_find_new_dequeue_state(), because the call to find_trb_seg() returned NULL. > > This happens two times in the log. Both times, it happens after the host > controller returns a COMP_STOP_INVAL completion code, for some reason. Is > there any way to tell from the log, what caused the COMP_STOP_INVAL to occur? > Maybe we need some more debugging code to track it down? Maybe. I'll take a look at when the xHCI spec says COMP_STOP_INVAL can be returned by the xHCI host controller. I've got about seven different xHCI bugs to track down right now (including your event seg null issue with the 3 hard drives), so it may take a bit. > One possibly strange thing I see, is that there is a single TRB on the TD list, > and the same TRB is also on the Cancelled TD list. Is it expected for the same > TRB to be on both lists? Yes, the TRB can be in both lists. It gets added to the cancelled TD list before the stop endpoint command gets queued, so the IRQ handler can figure out what to take off the hardware endpoint rings. If the TD completes before the stop endpoint command completes, then the TD is removed from both lists. If it's not completed and the stop endpoint command completes, then the IRQ handler turns the TRBs into no-ops or moves the dequeue pointer, and removes the TD from both lists. > This happened while running a USB-IF Gold Tree-like setup, and repeatedly > plugging and unplugging the entire tree from the xHC controller. (We have been > seeing problems with devices sometimes not being enumerated with the gold tree > setup.) > > The log is attached. I would appreciate it if you could have a look. Thanks. I'll take a look, thanks for reporting this! 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
