I decided to try the x86_64 version of CentOS 5 on my new desktop since it has an Athlon 64 X2 CPU. The one really perplexing oddity is that the monitor no longer goes to power save mode (standby) if the system is idle long enough (e.g., overnight). The "power management" option is set to put the display to sleep after thirty minutes. The display gets blanked but it never goes to standby. The weird thing is that the display behaved as expected when I still had the 32 bit version of CentOS installed so the hardware supports powering down the monitor. I don't see anything incriminating in dmesg, /var/log/messages or /var/log/Xorg.0.log. I'll switch the system to boot to runlevel 3 so I can see if X is spewing something to the first alternate console that isn't getting written to the log file. Anyone have other any suggestions as to diagnosing of fixing the problem? Thanks, Dave -- Politics, n. Strife of interests masquerading as a contest of principles. -- Ambrose Bierce
David G. Miller wrote:> I don't see anything incriminating in dmesg, /var/log/messages or > /var/log/Xorg.0.log. I'll switch the system to boot to runlevel 3 so I > can see if X is spewing something to the first alternate console that > isn't getting written to the log file. Anyone have other any > suggestions as to diagnosing of fixing the problem?Are there any DPMS options set in your xorg.conf ? What is your video card/monitor and what driver are you using in X ? Another thing to check is see if DPMS is enabled as an extension by your setup: xdpyinfo |grep DPMS should return "DPMS" I have to explicitly set my monitor power saving to off on my laptop otherwise the screen has a high likelyhood of not coming back on after turning off. Toshiba says it's a known behavioral issue with multi core laptops. Happened under XP as well. Yay for screen burn in. nate
Robert Nichols <rnicholsNOSPAM at comcast.net> wrote:> nate wrote: > >> > David G. Miller wrote: >> > >> >>> >> I don't see anything incriminating in dmesg, /var/log/messages or >>> >> /var/log/Xorg.0.log. I'll switch the system to boot to runlevel 3 so I >>> >> can see if X is spewing something to the first alternate console that >>> >> isn't getting written to the log file. Anyone have other any >>> >> suggestions as to diagnosing of fixing the problem? >>> >> > >> > Are there any DPMS options set in your xorg.conf ? What is your >> > video card/monitor and what driver are you using in X ? >> > >> > Another thing to check is see if DPMS is enabled as an extension >> > by your setup: >> > >> > xdpyinfo |grep DPMS >> > >> > should return "DPMS" >> > > And, see what "xset q" has to say about whether DPMS is currently > enabled or not. I've noticed that mplayer disables DPMS on entry, > but neglects to re-enable it on termination.Answering both suggestions: [dave at bend ~]# xdpyinfo |grep DPMS DPMS [dave at bend ~]# xset q Keyboard Control: auto repeat: on key click percent: 0 LED mask: 00000002 auto repeat delay: 500 repeat rate: 30 auto repeating keys: 00ffffffdffffbbf fadfffdfffdfe5ef ffffffffffffffff ffffffffffffffff bell percent: 50 bell pitch: 400 bell duration: 100 Pointer Control: acceleration: 2/1 threshold: 4 Screen Saver: prefer blanking: yes allow exposures: yes timeout: 0 cycle: 0 Colors: default colormap: 0x20 BlackPixel: 0 WhitePixel: 16777215 Font Path: unix/:7100,built-ins Bug Mode: compatibility mode is disabled DPMS (Energy Star): Standby: 0 Suspend: 0 Off: 0 DPMS is Enabled Monitor is On Font cache: Server does not have the FontCache Extension File paths: Config file: /etc/X11/xorg.conf Modules path: /usr/lib64/xorg/modules Log file: /var/log/Xorg.0.log These appear to be the same as another CentOS 5 box (but 32 bit) that correctly shuts down the monitor. xorg.conf looks like: [dave at bend ~]# cat /etc/X11/xorg.conf # Xorg configuration created by system-config-display Section "ServerLayout" Identifier "single head configuration" Screen 0 "Screen0" 0 0 InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection Section "Device" Identifier "Videocard0" Driver "vesa" EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "1600x1200" "1400x1050" "1280x1024" "1152x864" "1024x768" "800x600" "720x400" "640x480" "640x400" "640x350" EndSubSection EndSection and the video card is (this is a single card that shows up twice in lspci): 04:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Radeon X1300/X1550 Series] (prog-if 00 [VGA]) Subsystem: Diamond Multimedia Systems Unknown device 3000 Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at febf0000 (64-bit, non-prefetchable) [size=64K] I/O ports at e000 [size=256] Expansion ROM at febc0000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 Capabilities: [58] Express Endpoint IRQ 0 Capabilities: [80] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- 04:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300 Pro] (Secondary) Subsystem: Diamond Multimedia Systems Unknown device 3001 Flags: bus master, fast devsel, latency 0 Memory at febe0000 (64-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Capabilities: [58] Express Endpoint IRQ 0 When I know I'm going to be away from the system for "a while" I use the KVM to point to a vacant port. The monitor detects no signal and powers down but I have to remember to do this and I can't always predict how long I'll be away from the monitor. This is a traditional CRT (ViewSonic G220fb) so I'd rather no enrich the power company by supplying power to it for a black screen. Cheers, Dave -- Politics, n. Strife of interests masquerading as a contest of principles. -- Ambrose Bierce
"nate" <centos at linuxpowered.net> wrote:> David G. Miller wrote: > > >> > >> > Section "Device" >> > Identifier "Videocard0" >> > Driver "vesa" >> > EndSection >> > > [..] > > >> > and the video card is (this is a single card that shows up twice in lspci): >> > >> > 04:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Radeon >> > X1300/X1550 Series] (prog-if 00 [VGA]) >> > > any particular reason why your using the vesa driver on what seems to > be a fairly recent ATI card instead of the ATI specific drivers? Perhaps > the vesa driver doesn't work as well with power management(never used it > myself for very long). > > I'd try the ATI drivers and see if it fixes the behavior, you'll probably > get much better performance at the same time, with perhaps a bit less > stability depending on what you do. > > nateIt's what the install configurator came up with and the ati driver doesn't work with this video card (output from startx): ... (WW) RADEON: No matching Device section for instance (BusID PCI:4:0:1) found (WW) R128: No matching Device section for instance (BusID PCI:4:0:1) found (EE) No devices detected. Fatal server error: no screens found XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" after 0 requests (0 known processed) with 0 events remaining. I like getting a new install stable and fully functional with open source drivers before introducing perturbations like using a proprietary display driver. That being said, I just installed the ATI proprietary driver. So far the system is stable. I'll see whether the monitor correctly goes to a low power mode tonight. Cheers, Dave -- Politics, n. Strife of interests masquerading as a contest of principles. -- Ambrose Bierce
I wrote and now I'm answering my own post:> nate" <centos at linuxpowered.net> wrote: >> > David G. Miller wrote: >> > >> > >> >>>> >> > >>>> >> > Section "Device" >>>> >> > Identifier "Videocard0" >>>> >> > Driver "vesa" >>>> >> > EndSection >>>> >>> >> >>> >> > >> > [..] >> > >> > >> >>>> >> > and the video card is (this is a single card that shows up twice in lspci): >>>> >> > >>>> >> > 04:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Radeon >>>> >> > X1300/X1550 Series] (prog-if 00 [VGA]) >>>> >>> >> >>> >> > >> > any particular reason why your using the vesa driver on what seems to >> > be a fairly recent ATI card instead of the ATI specific drivers? Perhaps >> > the vesa driver doesn't work as well with power management(never used it >> > myself for very long). >> > >> > I'd try the ATI drivers and see if it fixes the behavior, you'll probably >> > get much better performance at the same time, with perhaps a bit less >> > stability depending on what you do. >> > >> > nate >> > It's what the install configurator came up with and the ati driver > doesn't work with this video card (output from startx): > > ... > (WW) RADEON: No matching Device section for instance (BusID PCI:4:0:1) found > (WW) R128: No matching Device section for instance (BusID PCI:4:0:1) found > (EE) No devices detected. > > Fatal server error: > no screens found > XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" > after 0 requests (0 known processed) with 0 events remaining. > > I like getting a new install stable and fully functional with open > source drivers before introducing perturbations like using a proprietary > display driver. That being said, I just installed the ATI proprietary > driver. So far the system is stable. I'll see whether the monitor > correctly goes to a low power mode tonight.The ATI proprietary driver seems to have fixed the problem. The monitor was in power save mode when I checked it this morning. The ATI Linux Driver wiki at http://wiki.cchtml.com/index.php/Red_Hat_Enterprise_Linux is very badly out of date. It has lots of dire warnings about things not working, work arounds required, etc. I pulled down the driver package from the ATI site, ran it to create a Red Hat rpm and installed the RPM. After I rebooted, everything just worked. I added some comments to the wiki to indicate that the problems described there only apply to RHEL/CentOS 5.0. Upgrading a 5.0 install to 5.1 or installing from 5.1 images and then installing the ATI proprietary driver is a piece of cake. It would be nice if the open source "ati" display driver got extended to include more recent ATI video cards. I'm now running a "tainted" kernel since I have the proprietary fglrx kernel module. Unfortunately, as with how this thread got started, lots of functionality isn't there with the "vesa" display driver. Cheers, Dave -- Politics, n. Strife of interests masquerading as a contest of principles. -- Ambrose Bierce