On Wed 03-10-18 16:46:05, Jan Kara wrote: > 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. Any news here? Are really ACPI tables wrong on this laptop? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
