This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 239075 - Unable to disable/change 20 minute monitor powersave
Unable to disable/change 20 minute monitor powersave
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: Adam Jackson
Depends On:
  Show dependency treegraph
Reported: 2007-05-04 15:13 EDT by numien
Modified: 2008-05-06 21:39 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-06 21:39:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)
Copy of /etc/sysconfig/hwconf (8.19 KB, text/plain)
2007-05-04 15:14 EDT, numien
no flags Details
Output from lsmod (2.70 KB, text/plain)
2007-05-04 15:15 EDT, numien
no flags Details
xorg.conf (1.42 KB, text/plain)
2007-05-29 13:57 EDT, numien
no flags Details
Xorg.0.log (54.45 KB, text/plain)
2007-05-29 13:59 EDT, numien
no flags Details
Xorg.0.log with no xorg.conf (56.26 KB, text/plain)
2007-05-29 14:49 EDT, numien
no flags Details
Xorg.0.log with no Load "glx" (bug not present) (22.78 KB, text/plain)
2007-05-29 15:08 EDT, numien
no flags Details

  None (edit)
Description numien 2007-05-04 15:13:51 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.
Comment 1 numien 2007-05-04 15:14:42 EDT
Created attachment 154160 [details]
Copy of /etc/sysconfig/hwconf
Comment 2 numien 2007-05-04 15:15:36 EDT
Created attachment 154161 [details]
Output from lsmod
Comment 3 David Zeuthen 2007-05-04 16:30:27 EDT
Does 'xset dpms force off' from a terminal do the trick? (move the mouse to get
the monitor back on)
Comment 4 numien 2007-05-04 16:48:48 EDT
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
[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.
Comment 5 David Zeuthen 2007-05-04 17:13:16 EDT
(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 problem / binary NVIDIA driver problem. Reassigning to
the appropriate component. Good luck.
Comment 6 numien 2007-05-05 21:59:20 EDT
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.
Comment 7 Matěj Cepl 2007-05-29 11:20:19 EDT
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.
Comment 8 numien 2007-05-29 13:57:46 EDT
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.
Comment 9 numien 2007-05-29 13:59:13 EDT
Created attachment 155611 [details]

Copy of /var/log/Xorg.*.log (only 0 existed) as requested.
Comment 10 numien 2007-05-29 14:49:16 EDT
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.
Comment 11 numien 2007-05-29 15:08:14 EDT
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 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.
Comment 12 numien 2007-05-29 15:38:54 EDT
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.
Comment 13 Bug Zapper 2008-04-03 20:30:29 EDT
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: to ensure this
doesn't happen again.
Comment 14 Bug Zapper 2008-05-06 21:39:33 EDT
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:

Note You need to log in before you can comment on or make changes to this bug.