kernel-packages team mailing list archive

[Sergio Gelato <Sergio.Gelato@xxxxxxxxxxx>]

Public bug reported:

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 in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1346269/comments/15
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
supporting.)

** Affects: linux (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 trusty

** Attachment added: "lspci -vvvnn output on EliteBook 850 G1"
   https://bugs.launchpad.net/bugs/1504003/+attachment/4488282/+files/lspci-vvvnn.log

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1504003

Title:
  Regression: spurious wakeup on HP EliteBook 850 G1

Status in linux package in Ubuntu:
  New

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
  in
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1346269/comments/15
  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
  supporting.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1504003/+subscriptions