On Fri, May 26, 2017 at 1:01 AM, Alan Stern <st...@rowland.harvard.edu> wrote: > On Thu, 25 May 2017, Kai-Heng Feng wrote: > >> > My mistake; we need to see the information from "lspci -vv -s 00:12.0" >> > with two "v"'s, not just one. >> >> Before wakeup: >> 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB >> EHCI Controller (rev 39) (prog-if 20 [EHCI]) >> Subsystem: Dell FCH USB EHCI Controller >> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- >> ParErr- Stepping- SERR- FastB2B- DisINTx- >> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >> Interrupt: pin A routed to IRQ 18 >> Region 0: Memory at fe769000 (32-bit, non-prefetchable) [size=256] >> Capabilities: [c0] Power Management version 2 >> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA >> PME(D0+,D1+,D2+,D3hot+,D3cold+) >> Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME- >> Bridge: PM- B3+ >> Capabilities: [e4] Debug port: BAR=1 offset=00e0 >> Kernel driver in use: ehci-pci > > Was this before you plugged in the mouse or after?
After. > > If it was after, it means there is a bug in the EHCI controller > hardware. This line: > >> Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME- > > says that the PME signal is not enabled, so the controller is not > sending a wakeup request. But when a new device gets plugged in, the > controller is supposed to ask to be woken up. Hmm, sounds bad. Is there any known workaround? Maybe wake up the host every two seconds? Or use a quirk to disable runtime PM for this host? > >> After wakeup: >> 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB >> EHCI Controller (rev 39) (prog-if 20 [EHCI]) >> Subsystem: Dell FCH USB EHCI Controller >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- >> ParErr- Stepping- SERR- FastB2B- DisINTx- >> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >> Latency: 32, Cache Line Size: 64 bytes >> Interrupt: pin A routed to IRQ 18 >> Region 0: Memory at fe769000 (32-bit, non-prefetchable) [size=256] >> Capabilities: [c0] Power Management version 2 >> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA >> PME(D0+,D1+,D2+,D3hot+,D3cold+) >> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >> Bridge: PM- B3+ >> Capabilities: [e4] Debug port: BAR=1 offset=00e0 >> Kernel driver in use: ehci-pci > > Yes, that is normal. > >> > There's another piece of information you can collect. Mount a >> > debugfs filesystem at /sys/kernel/debug, and then copy the contents of >> > the file >> > >> > /sys/kernel/debug/usb/ehci/0000:00:12.0/registers >> > >> > Do this while the controller is still asleep (after the mouse is >> > plugged in) and then again after it is awake. >> >> Before wakeup: >> bus pci, device 0000:00:12.0 >> EHCI Host Controller >> SUSPENDED (no register access) >> >> After wakeup: >> bus pci, device 0000:00:12.0 >> EHCI Host Controller >> EHCI 1.00, rh state running >> ownership 00000001 >> SMI sts/enable 0xc0080000 >> structural params 0x00200002 >> capability params 0x0000a076 >> status 4008 Periodic FLR >> command 0010015 (park)=0 ithresh=1 Periodic period=512 RUN >> intrenable 37 IAA FATAL PCD ERR INT >> uframe 2d5f >> port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT >> port:2 status 001000 0 ACK POWER sig=se0 >> irq normal 1855 err 10 iaa 98 (lost 0) >> complete 1865 unlink 10 > > Again, this is normal. > > 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
