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. How reproducible: 100%... maybe counts as higher if you consider I can't get it to go away. :) Additional info: 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 [root@nyx ~]# 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 [FAILED] [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.
(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 > > busy > [FAILED] > [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 before hald). 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] xorg.conf 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] Xorg.0.log 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' drivers. 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp