Hi Mathias, It seems you are right: entering echo on > /sys/bus/pci/devices/0000\:00\:14.0/power/control does tame USB to behave properly. However, every time the AC is plugged/unplugged, this value gets overridden. Any way to make this permanent? (I realise this would harm a tiny bit of my battery life, but I guess not enough for me to realise it). If you need any info to find a proper fix and help to test it, don't hesitate. Cheers, Pierre. Le jeudi 29 septembre 2016, 15:50:34 NZDT Mathias Nyman a écrit : > On 28.09.2016 22:08, Pierre de Villemereuil wrote: > > Hi! > > > > When entering "cat > > /sys/bus/pci/devices/0000\:00\:14.0/power/runtime_status", I got: > > - on battery: suspended > > - on AC: active > > Ok thanks, So current guess is that xhci-hcd driver suspend was called, > it stopped the xhci controller, and expects PCI code to put it to D3. > xhci-hcd driver assumes it will be woken up later by a PCI PME# event at > device connect, which will call the resume function for the xhci-hcd driver. > > But PCI never puts the controller to D3, and lspci shows xhci controller is > not capable of generating PME# events in D0 (PME(D0 shows "-") > > Capabilities: [70] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA > PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable+ DSel=0 > DScale=0 PME- > > So we get stuck in D0, incapable of generating PME#, with a stopped xhci > controller waiting for PME# to wake us up. > > I'll see if I can create a similar situation. > > Keeping the host on should help as a temporary workaround for you: > echo on > /sys/bus/pci/devices/0000\:00\:14.0/power/control > > There might be something in ACPI DSDT tables (provided by firmware) that > prevents PCI from putting xhci to D3. > > -Mathias -- 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
