Description of problem: Left alone for some, longer, time a machine presents a blank display. A monitor control LED blinks slowly green and orange which normally means some signal trouble. Attempts to revive X via keyboard and/or mouse manipulations failed. A network logon is still possible. Nothing remarkable in /var/log/XFree86.0.log beyond repeated at its bottom: ..... GetModeLine - scrn: 0 clock: 94500 GetModeLine - hdsp: 1024 hbeg: 1072 hend: 1168 httl: 1376 vdsp: 768 vbeg: 769 vend: 772 vttl: 808 flags: 5 GetModeLine - scrn: 0 clock: 94500 GetModeLine - hdsp: 1024 hbeg: 1072 hend: 1168 httl: 1376 vdsp: 768 vbeg: 769 vend: 772 vttl: 808 flags: 5 This is repeated 25 times. Nothing special in a 'ps' output as well. Sysrq key unfortunately not enabled. ATI Radeon VE/7000 QY PCI card with 64 MB of video ram. SMP Athlon on a Tyan board. An attempt to change a console on "remote" via 'chvt 1' hangs indefinitely with: ..... open("/dev/tty0", O_RDWR) = 3 ioctl(3, 0x4b33, 0xbffb7db3) = 0 ioctl(3, 0x5606, 0x1) = 0 ioctl(3, 0x5607, A full strace for 'chvt 1' attached. 'shutdown -h now' is effective and on a reboot a video is back. Version-Release number of selected component (if applicable): xorg-x11-0.6.6-0.2004_03_30.5 How reproducible: I do not know but I have seen something of that sort in the past already (although it was not really clear what happened and I never had that really documented).
Created attachment 99261 [details] A trace from an attempted 'chvt 1' with a lost video
I did not observe that for quite a while although I do not have a reliable procedure to make that happen.
I have 3 PCI Radeon 7000 boards locally, and may be able to attempt to reproduce this. I have an SMP Tyan motherboard, but not Athlon, although that may not matter. A useful script for attempting to trigger VT switch hangs which might be transient, is to put alternating calls to chvt in a shell script with a slight time delay between them. ie: while : do sleep 3 ; chvt 7 sleep 3 ; chvt 1 done That might make the problem more reproduceable if it seems transient. If you try this out, please let us know if the script idea above helps reproduce at all. Also, just out of curiousity, have you tested this system/card with Fedora Core 3 test1 or test2, or X.Org 6.8.0 or 6.8.1 at all? If you could attach an X server log from a problematic session, that would be useful also. We'll try to reproduce internally. Marking as a FC3Target bug. Thanks
> Also, just out of curiousity, have you tested this system/card > with Fedora Core 3 test1 or test2, or X.Org 6.8.0 or 6.8.1 at all? This particular graphics card sits in a box which happens to have a few different installations on it and one is a reasonably current FC3test (not test2 yet but this will likely happen later in the day). The reason why I did not observe the problem for some time could be that FC2 part have seen a rather sporadic use on this hardware in recent times.
Since this bugzilla report was filed, there have been several major updates to the X Window System, which may resolve this issue. Users who have experienced this problem are encouraged to upgrade to the latest version of Fedora Core, which can be obtained from: http://fedora.redhat.com/download If this issue turns out to still be reproduceable in the latest version of Fedora Core, please file a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component. Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates.