Red Hat Bugzilla – Bug 1031335
VIDEO: Suspend / Resume not working on the Intel/Haswell video based Acer Aspire S7 laptop ...
Last modified: 2015-06-29 08:57:01 EDT
Description of problem:
The laptop doesn't properly resume from Sleep or Hibernate modes. The screen
stays black (i.e. resumption of video does not happen). I can, however, SSH
into the laptop and interact with it (basically to reboot it).
Also, after Sleep/Hibernate and Resume, when I press-and-release the power
button (to try to trigger a shut down because there's nothing else I can do
at this point - other than ssh'ing onto the laptop), it too no longer responds. Press / release of the power button works fine otherwise to
shut down the O/S (just not after Sleep/Hibernate and Resume sequence).
So I basically have to press-and-hold the power button to power off the
laptop, and crash the O/S (because (1) it doesn't resume Video, and (2) a
press/release of the power button doesn't initiate a O/S shut down).
Version-Release number of selected component (if applicable):
Fedora 19 x86_64
Kernel: 3.11.7-200.fc19.x86_64 (and prior versions)
Every single time.
Steps to Reproduce:
1. sudo /usr/sbin/pm-suspend
2. Close/Open lid of the laptop
The laptop goes into Suspend mode, but upon resumption the Video
does not work. The O/S appears to otherwise be partially functioning,
as I can SSH into it and interact with it. But, for example, killing
the X server (to try to get to a Console command prompt) or doing anything else to try to restore LCD-video simply does not work.... Video is just gone.
The only thing left to do is press/hold the power button to power off
the laptop (crashing the O/S in the process); or SSHing into it from another
computer to reboot it.
Resumption of Video after Suspend/Hibernate.
This laptop uses the new Intel Haswell Video based graphics subsystem.
It does not user nVidia graphics.
If your brightness keys normally work, can you verify if you are actually
able to get the video back by increasing the brightness?
I've seen this phenomenon on a couple of occasions a few months ago
Thank you (we are also corresponding on a PowerOff issue with this same laptop). :).
The brightness keys do not work, even under normal operation (at least under XFCE4, which is what I use).
I forget which, but when I attempt increase/decrease brightness through the keys, or try other things to recover video, the screen starts to turn his weird
saturated dark green and gray color (but it's never bright or renders anything intelligible).
So before the screen gets washed-out or damaged from this, I quickly press
the power button to reboot.
I also notied that there was no /etc/X11/xorg.conf created by the install of Fedora 19 on this laptop. I don't know how that was possible. Does it not need /etc/X11/xorg.conf for the Intel/Haswell graphics card?
We're tracking some screen brightness issues with bug 903136 that may be related. Though if you're only seeing this on resume, it's probably some other bug.
Xorg hasn't needed an xorg.conf file in most cases for quite some time.
Hello... I was wondering if there is any progress on this.
I do wish the severity of this would be escalated because, in my case and quite likely other's too, a combination of this issue **and** a Power Off issue on this same ACER-S7 laptop (a bug that I reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1031331 ), makes operating this laptop family difficult:
- You can't Suspend/Resume or Hibernate/Resume, so you must shut down the O/S.
- Yet (see URL above) shutting down the O/S doesn't work without having to
press and hold the power button each time.
In general (like most laptop users) I prefer to Suspend or Hibernate this laptop and not have to shutdown and boot the O/S.
And note that upgrading from Fedora-19 to Fedora-20 yesterday, and now running kernel version 3.12.5-302.fc20.x86_64, both problems still persist.
Thanks in advance for your continued help. :)
*********** MASS BUG UPDATE **************
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.
Fedora 19 has now been rebased to 3.12.6-200.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20.
If you experience different issues, please open a new bug report for those.
Yes this is still a big issue.
As stated above (Comment #5) I have already been on Fedora 20 and using the latest kernel and the issue remains. IMHO it is a high priority issue because it kills battery life on laptops since you are unable to hibernate/suspend.
Thank you in advance for fixing this as soon as possible! I've been waiting for a while now. =:)
Can anyone provide guidance/suggestions on this issue (please and thanks)? I don't think any progress has been made on this bug (and no replies that directly speak to this problem). This is still failing on the latest version of Fedora (20) and released kernel. I do appreciate the efforts to fix this. Thank you. :)
Please try the 3.12.6 update and let us know if it fixes at least the poweroff issue. There was a pci bus master fix that went into 3.12.6 that fixed a number of issues related to that on Acer machines.
Thanks. Yes that was a separate bug that I filed (Bug ID: 1031331), and happily that particular problem, indeed, was resolved in the 3.12.6 kernel.
Sadly, I'm not getting any traction on this Video Suspend/Resume issue (probably because "Intel Haswell" based video is kind of new I'm guessing. Just speculation). :)
Since you can ssh in after the resume, can you do so and attach the output of the dmesg command here? I'm curious if there are any related messages from the kernel in dmesg.
Created attachment 846775 [details]
Output of "sudo dmesg" after Suspending and Resuming ...
"sudo dmesg" output attached. The problem seems to appear in line "923" and beyond. Snippet below, and full output is attached. Thank you. :)
[ ... snip ... ]
921 [ 57.087519] CPU3 is up
922 [ 57.092885] ACPI: Waking up from system sleep state S3
923 [ 57.143702] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
924 [ 57.176732] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
925 [ 57.198806] PM: noirq resume of devices complete after 76.858 msecs
926 [ 57.199618] PM: early resume of devices complete after 0.792 msecs
927 [ 57.199652] ------------[ cut here ]------------
928 [ 57.199684] WARNING: CPU: 0 PID: 88 at drivers/gpu/drm/i915/intel_pm.c:5342 i915_request_power_well+0x77/0x80 [i915]()
929 [ 57.199686] xhci_hcd 0000:00:14.0: setting latency timer to 64
930 [ 57.199687] mei_me 0000:00:16.0: irq 60 for MSI/MSI-X
931 [ 57.199711] Modules linked in: fuse nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT xt_conntr
ack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables vboxpci(OF) ip6table_nat vboxnetadp(OF) nf_conntrack
_ipv6 vboxnetflt(OF) nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw a
rc4 vboxdrv(OF) hid_multitouch uvcvideo acer_wmi iTCO_wdt sparse_keymap iTCO_vendor_support videobuf2_vmalloc snd_hda_code
c_realtek binfmt_misc videobuf2_memops iwlmvm snd_hda_codec_hdmi videobuf2_core mac80211 videodev media btusb bluetooth x8
6_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul mei_me
932 [ 57.199724] crc32c_intel mei ghash_clmulni_intel iwlwifi microcode snd_hda_intel snd_hda_codec cfg80211 joydev serio_r
aw snd_hwdep snd_seq i2c_i801 snd_seq_device rfkill snd_pcm i2c_designware_platform wmi snd_page_alloc tpm_tis i2c_designw
are_core snd_timer tpm snd tpm_bios lpc_ich shpchp mfd_core soundcore hid_logitech_dj raid0 i915 i2c_algo_bit drm_kms_help
er video drm i2c_core
933 [ 57.199726] CPU: 0 PID: 88 Comm: kworker/u16:5 Tainted: GF W IO 3.12.6-300.fc20.x86_64 #1
934 [ 57.199727] Hardware name: Acer Aspire S7-392/Storm2, BIOS V2.05 09/25/2013
935 [ 57.199759] ahci 0000:00:1f.2: setting latency timer to 64
936 [ 57.199767] Workqueue: events_unbound async_run_entry_fn
937 [ 57.199769] 0000000000000009 ffff8802516cdcb0 ffffffff816630c1 0000000000000000
938 [ 57.199770] ffff8802516cdce8 ffffffff810691dd ffff8802519ea400 ffff8802539b2098
939 [ 57.199772] ffff8802519ed000 ffffffff81a75523 0000000000000200 ffff8802516cdcf8
940 [ 57.199772] Call Trace:
941 [ 57.199776] [<ffffffff816630c1>] dump_stack+0x45/0x56
942 [ 57.199778] [<ffffffff810691dd>] warn_slowpath_common+0x7d/0xa0
943 [ 57.199780] [<ffffffff810692ba>] warn_slowpath_null+0x1a/0x20
944 [ 57.199793] [<ffffffffa00d7647>] i915_request_power_well+0x77/0x80
[ ... snip ... ]
Seems to be some odd interaction between the intel sound driver and the i915 display driver.
While I find it unlikely, does the issue go away if you don't have the vbox drivers loaded?
I removed VirtualBox (including drivers) and the problem persists.
The problem was actually present before I ever installed VirtualBox
(which was about a month after receiving the laptop and installed Fedora).
Btw... Thank you (and other behind the scenes) for your work in this.
Is there any update or ETA on this?
Still an issue as of kernel "3.12.8-300.fc20.x86_64"
(In reply to nmvega from comment #15)
> Good day...
> Is there any update or ETA on this?
> Still an issue as of kernel "3.12.8-300.fc20.x86_64"
> Thank you!
It is still a serious issue IMHO.
My Lenovo w510 laptop (with nvidia driver) on Fedora 20, latest updates, behaves exactly has mentioned (3.12.8-300.fc20.x86_64) in the original post.
To get back the correct suspend behavior I boot on the last Fedora 19 (3.12.7-200.fc19.x86_64).
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 20 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
(In reply to Fedora End Of Life from comment #17)
> This message is a reminder that Fedora 20 is nearing its end of life.
> bugs or makes them obsolete.
I have upgraded to Fedora 22 (Workstation with KDE, kernel 4.0) on a
Lenovo w540 and the bug is still there and deeply annoying.
Typically, changing the graphical configuration (through a sleeping state)
results in unpredictable and erratic behaviors. The only systematic
behavior is a full reboot.
I would say the present state of these bugs (there are additional bugs related to the KDE configuration tool) is much worse, from the user point of view, than with Fedora 21.
I just became aware of this bug. I've been helping Fedora users with various backlight issues and usually I've been able to get things working for them.
If you are still seeing one or both of the following 2 issues:
1) Brightness control does not work; and/or
2) Backlight is off after suspend/resume (*)
Then please file a new bug, with as Summary:
1) "Backlight control does not work on <vendor> <model>"
2) "Backlight off after suspend/resume on <vendor> <model>"
For component pick kernel, and assign the bug to me, or put me in the Cc.
For this bug please walk through: http://hansdegoede.livejournal.com/13889.html
and add a comment / attach all the results / logs requested there.
Note for nvidia binary driver users. Please switch to nouveau before reporting bugs, if the bug reproduces with nouveau I welcome bug reports, please use the nouveau driver for the duration of debugging the issue. If the problem only happens with the nvidia binary driver you are out of luck.
*) Please make sure that this is the problem and that the laptop has otherwise properly resumed, you can do this by shining a flashlight into the display at an angle, the light of the flashlight should then
enter the lcd and reflect from the reflector behind the backlight showing you part of the unlock screen. Also try to unlock and verify that at least works.
Thanks & Regards,
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.