On Wed 03-10-18 17:19:33, Mathias Nyman wrote: > 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 Sure. Attached. > 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) OK, thanks for the hint. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
Attachment:
dsdt
Description: Binary data
