[HP Spectre x360 - 13-4005dx] suspend/resume failure

Bug #1529266 reported by Stephen on 2015-12-25
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Unassigned

Bug Description

Upgrading from 15.04 to 15.10 my Spectre x360 is no longer able to suspend (either shutting the lid or sudo pm-suspend in a terminal). This is (AFAIK) the same problem as #1502531.

Following the instructions in #1502531 I updated to mainline kernel v4.4-rc6-wily and had no problems suspending the machine.

At the request of Chris Penalver I did the following:
 1. rebooted to the Ubuntu 4.2.0-22-generic kernel (since I've been running 4.4)
 2. ran sudo pm-suspend, system locked up (frozen mouse, caps lock key didn't light up when pressed)
 3. held the power button to shut laptop off
 4. booted into the 4.2.0-22-generic kernel again
 5. ran ubuntu-bug linux to generate this bug report

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: linux-image-4.2.0-22-generic 4.2.0-22.27
ProcVersionSignature: Ubuntu 4.2.0-22.27-generic 4.2.6
Uname: Linux 4.2.0-22-generic x86_64
ApportVersion: 2.19.1-0ubuntu5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: scbash 1551 F.... pulseaudio
CurrentDesktop: GNOME-Classic:GNOME
Date: Fri Dec 25 11:29:40 2015
HibernationDevice: RESUME=UUID=ab9ec8da-59c5-439b-b82d-c2f9eed12b3c
InstallationDate: Installed on 2015-05-22 (217 days ago)
InstallationMedia: Ubuntu-GNOME 15.04 "Vivid Vervet" - Release amd64 (20150422)
MachineType: Hewlett-Packard HP Spectre x360 Convertible 13
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-22-generic.efi.signed root=UUID=a70d7c75-082c-4180-9512-a509e815ff74 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.2.0-22-generic N/A
 linux-backports-modules-4.2.0-22-generic N/A
 linux-firmware 1.149.3
SourcePackage: linux
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: Upgraded to wily on 2015-11-12 (43 days ago)
dmi.bios.date: 10/20/2015
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: F.2C
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 802D
dmi.board.vendor: Hewlett-Packard
dmi.board.version: 58.41
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF.2C:bd10/20/2015:svnHewlett-Packard:pnHPSpectrex360Convertible13:pvr:rvnHewlett-Packard:rn802D:rvr58.41:cvnHewlett-Packard:ct10:cvrChassisVersion:
dmi.product.name: HP Spectre x360 Convertible 13
dmi.sys.vendor: Hewlett-Packard

Stephen (scbash) wrote :

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Changed in linux (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
Stephen (scbash) wrote :

The model number is 13-4005dx, HP's website claims the full name is "HP Spectre x360 - 13-4005dx (ENERGY STAR) (L0Q52UA)". Specs are here: http://www8.hp.com/us/en/products/laptops/product-detail.html?oid=7682004

Thanks.

tags: added: bios-outdated-f.2d
summary: - HP Spectre x360 suspend/resume failure
+ [HP Spectre x360 - 13-4005dx] suspend/resume failure
Stephen (scbash) wrote :

Ah, sorry about the out of date bios. Updating did not change the behavior at all. Unfortunately dmidecode fails on my machine:

scbash@aveline:~$ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
[sudo] password for scbash:
/dev/mem: Operation not permitted
scbash@aveline:~$ ls -l /dev/mem
crw-r----- 1 root kmem 1, 1 Dec 25 19:24 /dev/mem
scbash@aveline:~$ sudo lsattr /dev/mem
lsattr: Operation not supported While reading flags on /dev/mem
scbash@aveline:~$ sudo -i
root@aveline:~# dmidecode
# dmidecode 2.12
# SMBIOS entry point at 0xa9e84010
/dev/mem: Operation not permitted
root@aveline:~#

Please advise.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed

Stephen, the next step is to fully reverse commit bisect from kernel 4.2 to 4.4-rc6 in order to identify the last bad commit, followed immediately by the first good one. Once this commit has been identified, then it may be reviewed as a candidate for backporting into your release. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_reverse_bisect_the_upstream_kernel.3F ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

tags: added: needs-reverse-bisect
tags: added: latest-bios-f.2d
removed: bios-outdated-f.2d
Changed in linux (Ubuntu):
importance: Low → Medium
status: Confirmed → Incomplete
Stephen (scbash) wrote :

Before starting the reverse bisect I built v4.2 from kernel.org, and it does not reproduce the bug. I'm guessing I should try the Ubuntu kernel repository next?

Stephen, given the Ubuntu kernel first reported maps to upstream 4.2.6, you would want to test that first to confirm.

Stephen (scbash) wrote :

I see. The lack of 4.2.x tags in Linus's repo combined with the Ubuntu naming scheme (4.2.0-22) made me think it was still based on 4.2. I now have the linux-stable repo, and 4.2.6 does reproduce the problem. I'll start bisecting now, but at 90 minutes per build, it won't be fast...

From a documentation standpoint the KernelBisection wiki page does reference the kernel-stable repo, but I missed that because fairly early the page sends the reader to GitKernelBuild to prepare the system. Unfortunately GitKernelBuild only mentions Linus's repo.

Stephen (scbash) wrote :

Here are the results of the reverse bisect:

 $ git bisect start
 $ git bisect bad v4.4-rc6
 $ git bisect good v4.2.6
Bisecting: a merge base must be tested
[64291f7db5bd8150a74ad2036f1037e6a0428df2] Linux 4.2
 $ cp /boot/config-4.2.0-22-generic .config
 $ make oldconfig
 $ make clean
 $ time make -j5 deb-pkg LOCALVERSION=-custom-1
 $ cd ..
 $ ls
 $ sudo dpkg -i linux-image-4.2.0-custom-1_4.2.0-custom-1-2_amd64.deb linux-headers-4.2.0-custom-1_4.2.0-custom-1-2_amd64.deb
 $ sudo reboot
 $ git bisect bad
The merge base 64291f7db5bd8150a74ad2036f1037e6a0428df2 is bad.
This means the bug has been fixed between 64291f7db5bd8150a74ad2036f1037e6a0428df2 and [1c02865136fee1d10d434dc9e3616c8e39905e9b].

Looks like I need to do a forward bisect from 4.2 to 4.2.6 to determine when the bug was introduced?

Stephen (scbash) wrote :
Download full text (3.1 KiB)

I went ahead and did the forward bisect, here's the final step:

 $ git bisect good
0691783adb950a3839cc2bae5117c30e48c89539 is the first bad commit
commit 0691783adb950a3839cc2bae5117c30e48c89539
Author: Trond Myklebust <email address hidden>
Date: Sun Aug 30 18:37:59 2015 -0700

    NFSv4.1: Fix a protocol issue with CLOSE stateids

    commit 4a1e2feb9d246775dee0f78ed5b18826bae2b1c5 upstream.

    According to RFC5661 Section 18.2.4, CLOSE is supposed to return
    the zero stateid. This means that nfs_clear_open_stateid_locked()
    cannot assume that the result stateid will always match the 'other'
    field of the existing open stateid when trying to determine a race
    with a parallel OPEN.

    Instead, we look at the argument, and check for matches.

    Signed-off-by: Trond Myklebust <email address hidden>
    Signed-off-by: Greg Kroah-Hartman <email address hidden>

:040000 040000 cacf56a9f720cac415b4a20b597bfed7354d18ac aba15a8e370ad358f94d16ed4e6bb72fb7636daa M fs

And for the record, here's the log:

 $ git bisect log
git bisect start
# bad: [1c02865136fee1d10d434dc9e3616c8e39905e9b] Linux 4.2.6
git bisect bad 1c02865136fee1d10d434dc9e3616c8e39905e9b
# good: [64291f7db5bd8150a74ad2036f1037e6a0428df2] Linux 4.2
git bisect good 64291f7db5bd8150a74ad2036f1037e6a0428df2
# bad: [496c2053cd784dd653d295e499503f14907022b3] x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down
git bisect bad 496c2053cd784dd653d295e499503f14907022b3
# good: [9c67f424970dd732af60ed2378ff2f6bb7463edf] powerpc/pseries: Release DRC when configure_connector fails
git bisect good 9c67f424970dd732af60ed2378ff2f6bb7463edf
# bad: [9a04c65c6bcd5fea9e892d338f3d3da8df46c9a1] sctp: fix race on protocol/netns initialization
git bisect bad 9a04c65c6bcd5fea9e892d338f3d3da8df46c9a1
# bad: [7d36bc720a19bcd7be6161cbe36bb81914e30459] parisc: Filter out spurious interrupts in PA-RISC irq handler
git bisect bad 7d36bc720a19bcd7be6161cbe36bb81914e30459
# good: [18ea445c33dc60bebdc55348a882b1bb172ff05a] NFS: Don't let the ctime override attribute barriers.
git bisect good 18ea445c33dc60bebdc55348a882b1bb172ff05a
# bad: [8fd1f7a1c4bbfb43f3f17d12f5c60925ebd9dd6c] svcrdma: Change maximum server payload back to RPCSVC_MAXPAYLOAD
git bisect bad 8fd1f7a1c4bbfb43f3f17d12f5c60925ebd9dd6c
# good: [95141b15234777ad155895d1cb1e6f41eb2182ed] NFSv4: Force a post-op attribute update when holding a delegation
git bisect good 95141b15234777ad155895d1cb1e6f41eb2182ed
# bad: [0691783adb950a3839cc2bae5117c30e48c89539] NFSv4.1: Fix a protocol issue with CLOSE stateids
git bisect bad 0691783adb950a3839cc2bae5117c30e48c89539
# good: [f232178c124f70fddaeb81dfd82ec25c0fba58cc] NFSv4.1/flexfiles: Fix a protocol error in layoutreturn
git bisect good f232178c124f70fddaeb81dfd82ec25c0fba58cc
# first bad commit: [0691783adb950a3839cc2bae5117c30e48c89539] NFSv4.1: Fix a protocol issue with CLOSE stateids

Let me know if additional information would be helpful. I'll leave the 10+ test kernels installed for a few more days, but I'd like to clean them out as soon as possible (it's a cluttered boot menu right now...)

Thank...

Read more...

Stephen, to advise, what you did was a reverse (not forward) bisect.

Despite this, let this be marked Triaged for now, and the expectation would be that the identified commit is reviewed for backporting.

tags: added: cherry-pick reverse-bisect-done
removed: needs-reverse-bisect
Changed in linux (Ubuntu):
status: Incomplete → Triaged
tags: added: regression-release
Stephen (scbash) wrote :

Actually, I did both reverse and forward bisects (see comments 11 and 12 respectively), but by reverse bisect didn't find the fix because the problem commit, 0691783, is a cherry pick of 4a1e2fe from the 4.3 branch.

After locating the original commit I tested all the 4.3 releases and found they all demonstrate the bug. I've now isolated the fix between 4.3 and 4.4-rc1, so I'm starting a new reverse bisect to identify the fix.

Thanks.

Stephen (scbash) wrote :

The reverse bisect from 4.3 to 4.4-rc1 shows the bug was "fixed" in d55fc37, "Pull i2c updates from Wolfram Sang". That seems unrelated to the bad commit identified in 4.2.6 (0691783, "NFSv4.1: Fix a protocol issue with CLOSE stateids"), so either I botched the bisect or there might be something more complex going on.

For the record, here's the bisect log:

git bisect start
# good: [6a13feb9c82803e2b815eca72fa7a9f5561d7861] Linux 4.3
git bisect good 6a13feb9c82803e2b815eca72fa7a9f5561d7861
# bad: [8005c49d9aea74d382f474ce11afbbc7d7130bec] Linux 4.4-rc1
git bisect bad 8005c49d9aea74d382f474ce11afbbc7d7130bec
# good: [118c216e16c5ccb028cd03a0dcd56d17a07ff8d7] Merge tag 'staging-4.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect good 118c216e16c5ccb028cd03a0dcd56d17a07ff8d7
# good: [e6604ecb70d4b1dbc0372c6518b51c25c4b135a1] Merge tag 'nfs-for-4.4-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
git bisect good e6604ecb70d4b1dbc0372c6518b51c25c4b135a1
# bad: [b44a3d2a85c64208a57362a1728efb58a6556cd6] Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad b44a3d2a85c64208a57362a1728efb58a6556cd6
# good: [c0f3f90cf454dd845dcc443afa4f0e312a8eaee0] Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next
git bisect good c0f3f90cf454dd845dcc443afa4f0e312a8eaee0
# good: [42d4ebb42a17754d2e8344dc1aa486119671d0eb] Merge git://www.linux-watchdog.org/linux-watchdog
git bisect good 42d4ebb42a17754d2e8344dc1aa486119671d0eb
# bad: [a5e1d715a8d0696961d99d31d869aa522f1cad5a] Merge tag 'armsoc-cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad a5e1d715a8d0696961d99d31d869aa522f1cad5a
# good: [d3dc3df6330e4b4d799bef4aac6f934b5e726b1c] Merge tag 'omap-for-v4.4/soc-clean-up' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/cleanup
git bisect good d3dc3df6330e4b4d799bef4aac6f934b5e726b1c
# good: [c39dc960e9c5196022cbc46507d4782b6fc314f6] mfd: intel_quark_i2c_gpio: load gpio driver first
git bisect good c39dc960e9c5196022cbc46507d4782b6fc314f6
# bad: [d55fc37856244c929965c190c8e9dcb49e2c07aa] Merge branch 'i2c/for-4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
git bisect bad d55fc37856244c929965c190c8e9dcb49e2c07aa
# good: [174f2366b076db3876c3b7f595edf2aa739f9d43] i2c: au1550: Convert to devm_kzalloc and devm_ioremap_resource
git bisect good 174f2366b076db3876c3b7f595edf2aa739f9d43
# good: [2b630df721ee4c286d286ab5d5d958d34c86f067] i2c: i801: Document Intel DNV and Broxton
git bisect good 2b630df721ee4c286d286ab5d5d958d34c86f067
# good: [14cbc1d0e29667b0c01c9202fcf8ac31893f7daa] MAINTAINERS: i2c: drop i2c-pnx maintainer
git bisect good 14cbc1d0e29667b0c01c9202fcf8ac31893f7daa
# good: [75ecc64ef5a1f310fc80f732ad8cfb7e1bdc59d5] i2c: rcar: Revert the latest refactoring series
git bisect good 75ecc64ef5a1f310fc80f732ad8cfb7e1bdc59d5
# first bad commit: [d55fc37856244c929965c190c8e9dcb49e2c07aa] Merge branch 'i2c/for-4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers