[HP Compaq dc7800p Small Form Factor PC] suspend/resume failure

[Jeff Miller]

To reproduce this bug I go to the shell as root and execute pm-suspend.
Suspend to RAM fails to wake up on my HP dc7800p. After suspending with pm-suspend an attempt to wake the machine up with the power button leads to a black screen. The video card does not appear to show any activity to my monitor. I must hold the power button down for 6 seconds to power off and boot the system back up.

This system is using the on-board intel graphics. If I put an nvidia card into the machine it is able to suspend and resume without issue.

I have observed that if I pm-hibernate and resume from that hibernation the system is able to pm-suspend resume successfully.

I tested this but exists in an Ubuntu 14.04 installation. I have not tested or used it with older distributions.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: linux-image-3.19.0-21-generic 3.19.0-21.21
ProcVersionSignature: Ubuntu 3.19.0-21.21-generic 3.19.8
Uname: Linux 3.19.0-21-generic x86_64
ApportVersion: 2.17.2-0ubuntu1.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: jam 1272 F.... pulseaudio
Date: Mon Jun 22 18:15:33 2015
HibernationDevice: RESUME=UUID=142d4858-0a51-4f73-9a46-59d8983563fa
InstallationDate: Installed on 2015-06-18 (4 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
IwConfig:
 eth0 no wireless extensions.

 lo no wireless extensions.
MachineType: Hewlett-Packard HP Compaq dc7800p Small Form Factor
ProcEnviron:
 LANGUAGE=en_US
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-21-generic root=UUID=340b9404-d245-4c5f-b10a-bc2a2d4a5a9d ro quiet splash vt.handoff=7
PulseList:
 Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied
 No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.19.0-21-generic N/A
 linux-backports-modules-3.19.0-21-generic N/A
 linux-firmware 1.143.1
RfKill:

SourcePackage: linux
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/21/2011
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 786F1 v01.32
dmi.board.name: 0AA8h
dmi.board.vendor: Hewlett-Packard
dmi.chassis.type: 4
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvr786F1v01.32:bd07/21/2011:svnHewlett-Packard:pnHPCompaqdc7800pSmallFormFactor:pvr:rvnHewlett-Packard:rn0AA8h:rvr:cvnHewlett-Packard:ct4:cvr:
dmi.product.name: HP Compaq dc7800p Small Form Factor
dmi.sys.vendor: Hewlett-Packard

[Jeff Miller (jefferym)]

The attached dmesg output was taken after the reboot from a failed attempt.
For that failed attempt I had previously set /sys/power/pm_trace to 1.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Jeff Miller (jefferym)]

I get a response from ping when it is in the stuck state but I cannot SSH into the machine.

[Jeff Miller (jefferym)]

I installed the upstream kernel build from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1-rc2-vivid/ version 4.1.0-040100rc2-generic_4.1.0-040100rc2.201505032335_amd64

Attached is the /proc/acpi/wakeups file

[Jeff Miller (jefferym)]

The system, using the 4.1 kernel above, does not hang when I use pm_test core option (as well as any other test option in that file):

echo core > /sys/power/pm_test
echo 1 > /sys/power/pm_trace

dm-suspend

This seems to work and it resumes properly.

[Jeff Miller (jefferym)]

I did a pm-suspend with pm_trace and attached is the dmesg output.

It appears to have something after the magic value:

[ 2.496316] Magic number: 0:800:178
[ 2.496317] hash matches /home/kernel/COD/linux/drivers/base/power/main.c:1063
[ 2.496390] acpi device:0e: hash matches
[ 2.496407] platform: hash matches

[Jeff Miller (jefferym)]

I performed some tests by booting into single user mode with single on the grub line.

I tested, just a single invocation each of the following s2ram commands:

s2ram -f : fail
s2ram -f -a 1 : ok
s2ram -f -a 2 : fail - monitor powers on but gives a "non optimal mode" floating dialog from the monitor.
s2ram -f -a 3 : ok
s2ram -f -p -s : ok
s2ram -f -s : ok
s2ram -f -p : ok
s2ram -f -a 1 -m : ok
s2ram -f -a 1 -s : ok - says "Function not supported?" when it resumes but it seems to work.
s2ram -f -m : fail - montior comes on and complains of "non optimal mode"
s2ram -f -p -m : ok

Note, this is without the i915 module loaded. I can gather more module info on request in this state.

[Jeff Miller (jefferym)]

If I boot into single user mode, modprobe i195, and attempt the same steps I am unable to get s2ram to work.

[Jeff Miller (jefferym)]

That should be modprobe i915.

[Joseph Salisbury (jsalisbury)]

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.1 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1-unstable/

[Jeff Miller (jefferym)]

I installed from the 4.1-unstable link you provided.

cat /proc/version:

Linux version 4.1.0-040100-generic (kernel@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201506220235 SMP Mon Jun 22 06:36:19 UTC 2015

It failed to wake up from the suspend.
I have attached the dmesg output that I gathered from the machine after making it fail with /sys/power/pm_trace enabled.

[Jeff Miller (jefferym)]

I tested this with the latest upstream kernel and confirmed it is still a bug.

[Jeff Miller (jefferym)]

I confirmed that it still exhibits a successful pm-suspend immediately after a successful pm-hibernate.

I am attaching the dmesg immediately after the pm-hibernate/resume/pm-suspend/resume sequence.

[Jeff Miller (jefferym)]

This did not start happening after an upgrade. I have only tested this 15.04 and the 14.04 versions of ubuntu and they exhibit the issue. I have not tested or used other versions of ubuntu.

[penalvch (penalvch)]

Jeff Miller, could you please provide the missing information following https://wiki.ubuntu.com/DebuggingKernelSuspend ?

[Jeff Miller (jefferym)]

I followed the instructions with the kernel that was suggested previously. This process is the same as previously as well.

I open a terminal
sudo -s
echo 1 > /sys/power/pm_trace
pm-suspend

Press the power button, and the monitor fails to come back from resume.
I am unable to SSH in when it is in this state.

I reboot and saved the dmesg output as attached to the bug.

The result files are attached.

Is there something I am missing from the instructions? I believe I have followed them correctly.
Thanks

[penalvch (penalvch)]

Jeff Miller, the issue you are reporting is an upstream one. Could you please report this problem to the appropriate mailing list (linux-pm) by following the instructions verbatim at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked via http://vger.kernel.org/vger-lists.html . It can take a day for the new e-mail to show up in the respective archive.

Thank you for your understanding.