Re: USB hotplug on HP 255 G6 laptop

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

 



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



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

  Powered by Linux