On Fri, 11 Feb 2011, Sarah Sharp wrote: > On Wed, Feb 02, 2011 at 01:59:33PM -0500, Alan Stern wrote: > > The USB core keeps track of pending resume requests for root hubs, in > > order to resolve races between wakeup requests and suspends. However > > the code that does this is subject to another race (between wakeup > > requests and resumes) because the WAKEUP_PENDING flag is cleared > > before the resume occurs, leaving a window in which another wakeup > > request might arrive. > > > > This patch (as1447) fixes the problem by clearing the WAKEUP_PENDING > > flag after the resume instead of before it. > > I wonder if this was the race condition I was seeing with the USB 3.0 > hubs/split roothub patches. Alan, could the dmesg I posted on Jan. 14 > (subject: Issue with hub reset-resume under xHCI) be explained by this > bug? The only way these issues could be related would be if your host controller was autosuspending. The race in this patch occurs when the host controller is resumed and then the root hub generates a wakeup IRQ just before _it_ gets resumed. Furthermore, the damage caused by the race shows up when it causes the next host controller suspend to fail -- it doesn't mess up anything during the resume sequence. So I'd say these are unrelated. Have you made any progress on that hub reset-resume bug since the last message in the email thread (Jan. 18)? Alan Stern -- 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
