Re: USB hotplug on HP 255 G6 laptop

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

 



On 02.10.2018 17:53, Jan Kara wrote:
On Tue 02-10-18 17:01:54, Mathias Nyman wrote:
On 02.10.2018 16:06, Jan Kara wrote:
Hello,

my wife has HP 255 G6 laptop. When it is attached to AC, everything works
as expected however when it is running on battery, USB hotplug stops
working - newly plugged devices do not appear to be visible to the kernel.
Only when the AC is plugged back in, the kernel suddently wakes up and
detects all newly attached devices. Maybe it is related to some power
management? Any idea how to debug this? Dmesg from the system is attached.
The kernels I've tested with (both behave the same way) are 4.18.11 kernel
and also openSUSE Leap 15 kernel which is 4.12-based. Thanks in advance for
any help.


Are you running laptop mode tools or similar that would enable runtime suspend
D3 state for xhci controller?

It is openSUSE Leap 15 installation with xfce4 desktop so I assume there is
some power-management going on. Not sure what I should look for but there's
xfce4-power-manager running, also upowerd is running.

what does lspci -vv say?

Attached.

check the content of the following files while running on battery:

cat /sys/bus/pci/devices/0000:00:10.0/firmware_node/power_state

D0

cat /sys/bus/pci/devices/0000:00:10.0/power/control

auto - when on battery, on - when on AC.

try: echo on > /sys/bus/pci/devices/0000:00:10.0/power/control
before pluggin in a usb device, does it help?

Yes, USB device gets recognized after this.


To me this looks like xhci is runtime suspended, but controller is still in a PCI D0 state.

Normally the xHC should be put to PCI D3 in runtime suspend,  and woken up by a PCI PME#
when a device is plugged in, but PME# is not enabled in D0 so in this case nothing wakes
up the xHC.

The xhci runtime suspend code already stopped the controller, so probably you're not
getting an interrupt either.

PCI code looks at firmware ACPI tables to choose the suspend D state, if something is off in the
tables it's possible the wrong state is chosen. worth checking.

Could you dump the DSDT ACPI table form /sys/firmware/acpi/tables/DSDT

As a quick temporary workaround you could find and prevent the powersaving program from enabling
runtime suspend. (make sure it won't write "auto" to /sys/bus/pci/devices/0000:00:10.0/power/control)

-Mathias



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

  Powered by Linux