Hi Sarah > That particular error is from the host side. It means the xHCI driver > tried to move the ring dequeue pointer past the last part of your > command (probably the status phase), and the host refused to do so, > because that was the "active" stream ID. Can you please send me the > full dmesg for the stalled request with CONFIG_USB_XHCI_HCD_DEBUGGING > turned on? Np. I've already overcame this issue but I'll roll back and send you the dmesg output. When I tried enabling this flag the dmesg was swamped with xhci messages and the messages I was looking for weren't there already. I read that in order to increase the dmesg buffer size one needs to update the #define of LOG_BUF_LEN in linux/kernel/printk.c. I haven't tried that yet. Is this correct? Do you need the LECroy recording as well? > > I think it's worth rolling back your firmware for this because I really > need to test this corner case. I think it may be an unhandled corner > case that I've been warning Intel's xHCI spec architect about. There > seems to be no way to modify the active stream's rings for cases like > these where the transfer stalls. > > Which host controller are you running under? If it's an NEC host > controller, please send me the line that looks something like this: > > NEC firmware version xx.xx > We're using NEC but I'm not sure where to retrieve the version from. The line you mentioned isn't present in the dmesg output and I found nothing similar written on the chip either. Best regards, Tanya Brokhman Consultant for Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- 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
