On Mon, 23 Apr 2018, Mathias Nyman wrote: > On 22.04.2018 09:29, russianneuromancer@xxxxx wrote: > > Hello! > > > > So far I tested attached patch but didn't tried to revert commit yet, > > will do next week. > > > > Result of running patched kernel with recommended debug options: > > https://paste.fedoraproject.org/paste/UpezexD~tDmQthoxV2BFbg > > > > Logs show there is a race, controller is suspended, then resumed, > but no interrupt is pending in xhci_resume so roothubs are not resumed, > and host starts to suspend again. > > We get the interrupt only after we already started suspending xhci > controller again. > > My guess is that when we handle the interrupt we queue work to resume the roothub, > but controller is probably put to D3 suspended state by then, > returning 0xffffffff from some register reads, which driver understands as a dead host. > > I need to look into this a bit more. In this situation, the HCD_WAKEUP_PENDING(hcd) test in hcd-pci.c:suspend_common() should prevent the controller from going back into D3. The WAKEUP_PENDING bit gets set in usb_hcd_resume_root_hub() and it doesn't get cleared until hcd_bus_resume() runs. 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
