← Back to team overview

kernel-packages team mailing list archive

[Bug 1504003] Re: Regression: spurious wakeup on HP EliteBook 850 G1


[Expired for linux (Ubuntu) because there has been no activity for 60

** Changed in: linux (Ubuntu)
       Status: Incomplete => Expired

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.

  Regression: spurious wakeup on HP EliteBook 850 G1

Status in linux package in Ubuntu:

Bug description:
  Starting with Ubuntu kernel 3.13.0-44.73, the system spuriously
  reboots instead of powering off. Kernels up to 3.13.0-43.72 are not
  affected. The problem is 100% reproducible. It has also been mentioned
  but that bug report was originally about different hardware (Lynx
  Point, not Lynx Point-LP) and should not be hijacked to discuss the
  EliteBook 8x0. The same holds for bug #1320282.

  Kernel 3.19.0-30 is also affected. The problem persists if the system
  is booted with xhci_hcd.quirks=0x2000 (XHCI_SPURIOUS_REBOOT) but goes
  away if one boots with xhci_hcd.quirks=0x40000 (XHCI_SPURIOUS_WAKEUP).

  I've almost completed a bisection between 3.13.0-43.72 and
  3.13.0-44.73. The remaining commits include both "xhci: Switch only
  Intel Lynx Point-LP ports to EHCI on shutdown." and "xhci: no
  switching back on non-ULT Haswell", however both the hardware
  configuration (Lynx Point-LP, 8086:9c31) and the above mentioned tests
  with quirk bit settings strongly suggest it's the latter commit that
  is at fault and that on this particular hardware (ULT Haswell) one
  needs *both* XHCI_SPURIOUS_REBOOT (automatically enabled by all the
  kernels I mentioned) and XHCI_SPURIOUS_WAKEUP.

  I have only intermittent access to an affected system and limited
  interest in spending more time on this now that a workaround (run a
  newer kernel with xhci_hcd.quirks=0x40000) is known. However, my
  findings so far may be valuable to others.

  A look at the current linux-stable source tree on git.kernel.org
  suggests that the problem has yet to be addressed upstream (unless
  it's fixed/masked by some other change elsewhere in the code; I
  haven't actually tested the latest upstream kernel).

  The output of lspci -vvvnn (not -vnvn, sorry; I hope it's good enough)
  is attached.

  We've tried BIOS revisions 1.30 and 1.33. (1.33 is the latest, and
  1.30 was a critical update so anything older is probably not worth

To manage notifications about this bug go to: