Red Hat Bugzilla – Bug 808942
unable to change screen brightness after suspend on Thinkpad W520
Last modified: 2013-07-31 22:09:34 EDT
Description of problem:
Unable to adjust screen brightness after suspending machine. Tried keyboard fn keys as well as the screen brightness software controls. Worked fine before suspend, after suspend nothing happens. Trying the 'yum reinstall bash' hack doesn't help.
Machine is a Lenovo Thinkpad W520 with nVidia Quadro 1000 graphics in descrete (nvidia) graphics mode booted with noapic kernel flag and using the standard nouveau driver running fresh, stock, fully yum updated installs of f16 and f17.
Version-Release number of selected component (if applicable):
16 and 17
Steps to Reproduce:
1. suspend to ram
2. try to adjust screen brightness
screen brightness to change
*** Bug 796904 has been marked as a duplicate of this bug. ***
As of 6/30/12 this problem still exists on f17. I'm fully yum updated running 3.4.3-1.fc17.x86_64 kernel.
Same problem here on F16 with kernel-3.4.2-1.fc16.x86_64.
The problem only occurs when using the Nvidia hardware; if Intel is selected in the BIOS, brightness controls work.
(It looks like Intel mode unfortunately does no VGA output, that's the only reason I'm trying Nvidia...)
I can confirm this problem occurs in Fedora 18 x86_64 that's been updated to the yum repositories for Fedora as of 2/15/2013.
laptop: Toshiba P945-P440, version: PT43NU-003001
baseboard version (from dmidecode): A0
BIOS: version 2.00 release date: 5/24/2012
kernel version 3.7.7-201.fc18.x86_64
1) boot laptop as usual, enter into KDE as user,
KDE laptop brightness plasma controls work as expected.
2)use KDE suspend to RAM control on desktop (currently using the plasma widget) to suspend laptop
3) laptop suspends as expected
4) unsuspend by pressing power button
5) KDE brightness controls no longer work
6) running dmesg finds this error which is always associated to brightness failure (this error is never in dmesg unless at least one suspend cycle has occurred):
[ 1.312655] ACPI Error: [GTF0] Namespace lookup failure, AE_NOT_FOUND (20120913/psargs-359)
[ 1.312658] ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.PRT0._SDD] (Node ffff88022387ecd0), AE_NOT_FOUND (20120913/psparse-536)
[ 1.312697] ACPI Error: [GTF0] Namespace lookup failure, AE_NOT_FOUND (20120913/psargs-359)
[ 1.312699] ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.PRT0._GTF] (Node ffff88022387ecf8), AE_NOT_FOUND (20120913/psparse-536)
[ 1.312793] ata1.00: ATA-9: SAMSUNG SSD 830 Series, CXM03B1Q, max UDMA/133
[ 1.312795] ata1.00: 250069680 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 1.313069] ACPI Error: [GTF0] Namespace lookup failure, AE_NOT_FOUND (20120913/psargs-359)
[ 1.313071] ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.PRT0._SDD] (Node ffff88022387ecd0), AE_NOT_FOUND (20120913/psparse-536)
[ 1.313107] ACPI Error: [GTF0] Namespace lookup failure, AE_NOT_FOUND (20120913/psargs-359)
[ 1.313110] ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.PRT0._GTF] (Node ffff88022387ecf8), AE_NOT_FOUND (20120913/psparse-536)
Note: cat /proc/cmdline was:
BOOT_IMAGE=/vmlinuz-3.7.7-201.fc18.x86_64 root=UUID=3a2a1ac7-2def-48bb-bb91-641829a581f0 ro rootflags=subvol=root acpi_sleep=s3_beep rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole.keymap=us
"acpi_sleep=s3_beep" was attempted to try to work around this after reading on a forum post that this option helped work around this. It didn't help in my case. Brightness control doesn't work after suspend with or without that option in my testing.
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. 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 WONTFIX if it remains open with a Fedora
'version' of '17'.
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 prior to Fedora 17's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life.
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.
The same Fedora 18 laptop I reported as showing this bug in comments 4 & 5 works now that the kernel has moved on (using 3.9.8-200.fc18.x86_64 ) now. Either the newer kernels fix it or some intervening package fix did it.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.
Thank you for reporting this bug and we are sorry it could not be fixed.