Le mar. 24 sept. 2019 à 17:50, Loïc Yhuel <loic.yhuel@xxxxxxxxx> a écrit : > > Looks like the xHCI PCI controller wasn't fully powered up to D0 state yet > > when xhci_resume was called. Looks similar to what is discussed in thread: > > > > https://marc.info/?l=linux-usb&m=156681068319529&w=2 In fact the kernel keeps the device, port, and the two bridges in D0 state. On suspend : [ 860.578478] xhci_hcd 0000:08:00.0: PME# enabled [ 860.578511] xhci_hcd 0000:08:00.0: PCI PM: Suspend power state: D0 ... [ 860.580329] pcieport 0000:02:09.0: PCI PM: Suspend power state: D0 ... [ 860.603786] pcieport 0000:01:00.2: PCI PM: Suspend power state: D0 [ 860.603836] pcieport 0000:00:01.1: PCI PM: Suspend power state: D0 On resume : <restoring config space for 0000:02:09.0, then 0000:08:00.0> ... [ 861.135868] xhci_hcd 0000:08:00.0: PME# disabled [ 861.135934] xhci_hcd 0000:08:00.0: enabling bus mastering ... [ 861.235966] xhci_hcd 0000:08:00.0: WARN: xHC restore state timeout [ 861.235972] xhci_hcd 0000:08:00.0: PCI post-resume error -110! [ 861.235973] xhci_hcd 0000:08:00.0: HC died; cleaning up [ 861.235981] PM: dpm_run_callback(): pci_pm_resume+0x0/0x90 returns -110 [ 861.235984] PM: Device 0000:08:00.0 failed to resume async: error -110 Setting the XHCI_RESET_ON_RESUME quirk avoids the issue. But the real problem might be the device being marked as only supporting D0, which seems strange for suspend. > On my machine, the PCIe "port" is supposed to support 8GT/s (but the > controller is on the motherboard, > so there is no official specification about how the internal > peripherals are linked), the device too, > but it's always in 5GT/s mode (in Windows too), so perhaps it changes > the delays. This is unrelated to the other problems, but if someone else has the same HW, I found I can enable 8GT/s : setpci -v -s 0000:08:00.0 CAP_EXP+0x30.w=0x0003:0x000f setpci -v -s 0000:02:09.0 CAP_EXP+0x30.w=0x0003:0x000f setpci -v -s 0000:02:09.0 CAP_EXP+0x10.w=0x0020:0x0020
