On Mon, Feb 25, 2013 at 04:38:06PM +0800, Soar Hung wrote: > > > -----Original Message----- > > From: Lan Tianyu [mailto:lantianyu1...@gmail.com] > > Sent: Wednesday, February 20, 2013 4:14 PM > > To: Soar Hung > > Cc: Alan Stern; Sarah Sharp; linux-usb@vger.kernel.org > > Subject: Re: Not enough resource for old configuration after > > USB bus reset > > > > 2013/2/19 Soar Hung <soarh...@realtek.com>: > > > Hi all, > > > > > > I checkout the usb-next branch (on 2/18) and following the > > https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to build the kernel. > > > > > > After reboot, the new kernel version is Linux dev > > 3.8.0-rc5-usbnext #1 SMP Mon Feb 18 18:04:02 CST 2013 i686 > > i686 i386 GNU/Linux. > > > > > > I try the same operation to produce the issue, and it also fails. > > Please attach the output of dmesg with CONFIG_USB_DEBUG and > > XHCI_DEBUG. > > With these two debug config on, the dmesg buffer even can not log one reset > operation.
You can increase your buffer size by setting CONFIG_LOG_BUF_SHIFT=21. > What information do we want from these two debug config? Everything. I'd like to understand exactly what's happening at the xHCI driver level. I probably only need to see three reset cycles. Zip up the log file or use pastebin if you think the log file is too big. > We currently know that the issue is fail at the configure endpoint > command after bus reset. > > The failing reason is the reset operation make the endpoint state > disabled, and HCD still try to drop the disabled endpoint. > > This cause the host can not manage its resouce correctly. As a result, > the last configure command fail with not enough bandwidth. Are you saying the xHCI driver is trying to issue a Configure Endpoint command with the drop flag set for an endpoint that was removed by the Reset Device command? If so, I would like to see the log files so I can debug why that happened. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
