On Tue, 26 Feb 2013, Tony Camuso wrote: > On 02/25/2013 05:15 PM, Alan Stern wrote: > > > > Probably because the buses are registered at boot but there aren't > > any devices plugged in. (Or maybe there are devices, but the system > > is too busy doing other things during boot to detect them for a > > while.) Since the buses are idle, they get suspended. > > > > Then should I continue to pursue relocating calls to init and delete > the compliance mode recovery timer to xhci_bus_suspend/resume?
I don't know. If you think the scheme will work then pursue it, otherwise don't. > > On Mon, 25 Feb 2013, Tony Camuso wrote: > >> Furthermore, xhci_bus_suspend is called before xhci_bus_resume, so > >> an attempt is made to delete the compliance mode recovery timer, > >> which does not yet exist. This produces a list_add corruption call > >> trace a number of times during boot. > > > > That doesn't make sense. > > You are correct. It's when xhci_bus_resume is called that we get the > list_add corruption. Why is that? As far as I know, xhci_bus_resume is never called without xhci_bus_suspend being called first. Hence the timer should not be on the list when xhci_bus_resume runs. > Presently, the timer is added in xchi_init() and xhci_resume(). Our problem > emerges when xhci_resume tries to add the timer after it has been restored > by resuming from hibernate. In the new scheme, the timer should not be added by xhci_resume. Alan Stern -- 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
