Bug 1031335

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

Hi Michele:

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?

Thank you!

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.

Thank you.

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. =:)

Good morning.

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.

Hi Josh:

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?

Hi Josh:

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.

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!

(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'
of '20'.

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.

Hi All,

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,

Hans

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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.