Red Hat Bugzilla – Bug 239075
Unable to disable/change 20 minute monitor powersave
Last modified: 2018-04-11 10:14:31 EDT
Description of problem:
I actually had this problem with FC6 too, never figured out why... no matter
what I try to do, nothing I've found changes my monitor going into powersave
standby after 20 minutes.
I've done the Power Management settings, used the automatic sleep inhibitor
applet, tried both "nv" and "nvidia" drivers, made sure BIOS isn't set to do
that itself, nothing has mattered... it's always exactly 20 minutes.
Version-Release number of selected component (if applicable):
Not sure which component it is, gnome-power-manager was picked because it
wouldn't let me submit it without one. Everything is up-to-date as of this writing.
100%... maybe counts as higher if you consider I can't get it to go away. :)
I'm not sure how to get the nice hardware profile shown in installation, but
I've attached a copy of my /etc/sysconfig/hwconf and output from lsmod in hopes
they're useful. Let me know if anything else would help.
Created attachment 154160 [details]
Copy of /etc/sysconfig/hwconf
Created attachment 154161 [details]
Output from lsmod
Does 'xset dpms force off' from a terminal do the trick? (move the mouse to get
the monitor back on)
Hmmm. That's interesting...
[root@nyx ~]# xset dpms force off
server does not have extension for dpms option
xset: unknown option force
My xorg.conf Monitor section does have DPMS enabled in it. Xorg.0.log indicates
DPMS is being loaded, or at least attempting to be:
(**) Option "dpms"
(**) NVIDIA(0): DPMS enabled
But, I'm not sure if it requires acpid, since that appears to fail:
(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
(II) No APM support in BIOS or kernel
Seems acpid isn't running, and won't start:
[root@nyx ~]# service acpid start
Starting acpi daemon: acpid: can't open /proc/acpi/event: Device or resource busy
Checking "lsof | grep proc/acpi/event" shows hald-addon-acpi is using it.
From what I understand, hald is fairly important, so I probably couldn't kill
that in favour of acpid... if I'm wrong let me know and I can try it.
(Please don't change the version from 'devel' - for practical purposes 'test4'
is just broken; I don't know why it still lingers around)
> [root@nyx ~]# service acpid start
> Starting acpi daemon: acpid: can't open /proc/acpi/event: Device or resource >
> [root@nyx ~]#
> Checking "lsof | grep proc/acpi/event" shows hald-addon-acpi is using it.
> From what I understand, hald is fairly important, so I probably couldn't kill
> that in favour of acpid... if I'm wrong let me know and I can try it.
If acpid is running, hald will use that instead of connecting directly to the
kernel socket. So just make sure acpid is started in the initscripts (it starts
Anyway, this is an X.org problem / binary NVIDIA driver problem. Reassigning to
the appropriate component. Good luck.
Enabling both hald and acpid (via chkconfig) and restarting caused acpid to load
successfully, and Xorg to recognize it.
However, the 'xset dpms force off' command still fails with that error, and the
screen still turns off at exactly 20 minutes no matter what the settings are.
Guess that was unrelated.
Thanks for the bug report. We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.
Please, note, that we are unable to support proprietary binary-only drivers, so
please make sure, that all logs etc. are generated only with open source (nv in
this case) drivers.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 155610 [details]
My /etc/X11/xorg.conf file, as requested.
Normally I run using the 'nvidia' binary driver, but this (and the log file in
the next attachment) are done using the 'nv' GPL driver.
Identical problem with both drivers.
Created attachment 155611 [details]
Copy of /var/log/Xorg.*.log (only 0 existed) as requested.
Created attachment 155616 [details]
Xorg.0.log with no xorg.conf
Copy of /var/log/Xorg.*.log with no /etc/xorg.conf file.
This actually fixed the problem. "xset dpms force off" worked instead of giving
an error, and it didn't go into powersave at 20 minutes.
Will try changing things in xorg.conf to see if I can narrow it down a bit, and
post again here if I figure out anything useful.
Created attachment 155619 [details]
Xorg.0.log with no Load "glx" (bug not present)
Ok, problem isolated. If I comment out the 'Load "glx"' entry in the Modules
section (leaving the section blank) it works fine, with both 'nv' and 'nvidia'
The Xorg.0.log file still indicates glx being loaded, too. It's using X.org glx
(with either driver) but that's the same as before commenting that entry out,
when the problem was still present.
Does forcing the load in xorg.conf cause it to load in a different order? Maybe
that's what's triggering the problem.
Yeah, just reinstalled nvidia binary driver, made sure that entry was commented
out, and restarted X. Loads fine, with hardware OpenGL and everything.
It's very specifically having that line in the config file which causes the problem.
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.
If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.
The process we're following is outlined here: