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 <j...@suse.com>
SUSE Labs, CR
