Re: Runtime PM enabled EHCI does not respond to device plugging.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 26, 2017 at 1:01 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux