Bug 582264

Summary: [RV620] blank screen for laptop w/ Radeon HD 3400 / [1002:95c4] test day
Product: [Fedora] Fedora Reporter: Nick Lamb <redhat>
Component: xorg-x11-drv-atiAssignee: Jérôme Glisse <jglisse>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 14CC: amrlima, fropeter, mcepl, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 18:22:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Newly created xorg.conf file generated as none existed
none
/var/log/Xorg.0.log
none
/var/log/Xorg.9.log
none
output of dmesg command
none
/var/log/messages
none
/etc/X11/xorg.conf.d/00-system-setup-keyboard.conf none

Description Nick Lamb 2010-04-14 14:12:03 UTC
Description of problem:

Hardware is: http://www.smolts.org/client/show/pub_62923515-d6d0-431e-b8e8-e2d6ae6d2eb3

With the 20120412 testday x86-64 image, the screen eventually (after unpredictable length of time in use) blanks suddenly (ie even between keystrokes sometimes) and never unblanks.

This is using the same hardware as bug 557805 and is very similar except

• Jerome is "100% sure" that bug 557805 lockups are somehow caused by the package management system, although he can't point to any particular affected file or package.

• This doesn't always hard-lock the machine, switching blindly to a VT (which is also blank) and pressing Ctrl-Alt-Delete may reboot it.

Thanks to the latter I will try to see if I can get log files after this event on a future occasion. But I don't know how soon that will be.

Comment 1 Bug Zapper 2010-07-30 11:20:40 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 2 fropeter 2010-11-13 01:44:32 UTC
This seems to be the same or similar to what I am experiencing. I had this problem on F12 as well, but then I could most times switch to a different VT and back to get the screen working again. On F14 I have to suspend by shutting the lid and open/resume to get the screen image back. 

I created a hotkey that put a timestamp in /var/log/messages and used that immediately after the screen shut down, but I could not find anything in that log that seemed relevant around the time in question. The x.org.logs are not timestamped. I am not shure if this is X, ati-driver or something else, like maybe power management (which controls suspend/resume).

In case it is relevant, and I don't know if this would be the same issue: I have experienced something similar on a stationary computer using F10 and possibly F12, but then either when shutting down or switching users. The screen blanks, only showing i white rectangle as mouse pointer. Switching to a different VT and back brings back the image in this case too. (It has a Radeon X800 card, but I don't remember the exact driver used).

Both these errors are very unpredictable in occurence, but more frequent on the laptop (both on F12 and F14).

I have googled this from time to time, and it seems this isn't a rare problem, so I wonder if the priority of this bug being set to 'low' is appropriate.

http://www.smolts.org/client/show/pub_77a7a044-2468-4774-8dec-977fb19df6c6

Please advice as to how I can help locating the problem (aside from reading code).

Comment 3 Matěj Cepl 2010-11-15 00:00:48 UTC
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 add drm.debug=0x04 to the kernel command line, restart computer, and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 4 fropeter 2010-11-16 00:25:21 UTC
Created attachment 460699 [details]
Newly created xorg.conf file generated as none existed

The requested /etc/X11/xorg.conf file didn't exist on this machine, so I generated one as root in a console, using "Xorg -configure :1"
I don't know if this reveals any new details, but just in case..

Comment 5 fropeter 2010-11-16 00:27:29 UTC
Created attachment 460700 [details]
/var/log/Xorg.0.log

Comment 6 fropeter 2010-11-16 00:28:19 UTC
Created attachment 460701 [details]
/var/log/Xorg.9.log

Comment 7 fropeter 2010-11-16 00:29:18 UTC
Created attachment 460702 [details]
output of dmesg command

Comment 8 fropeter 2010-11-16 00:30:44 UTC
Created attachment 460705 [details]
/var/log/messages

Comment 9 fropeter 2010-11-16 00:34:40 UTC
Created attachment 460707 [details]
/etc/X11/xorg.conf.d/00-system-setup-keyboard.conf

I don't know whether this is relevant, but since Xorg isn't using a xorg.conf file and this probably overrides parts of it, I thougt it best to include it. Ther are no other files in the directory.

Comment 10 fropeter 2010-11-16 00:40:03 UTC
Just in case you wonder about the _output.txt part of some of the filenames: I used cat and redirect to a file instead of simply copying the files in question. It's to late to be doing this... ;-)

Comment 11 fropeter 2010-11-16 00:42:19 UTC
Booted with drm.debug=0x04 on the kernel line in grub, provided all requested files.

Comment 12 António Lima 2010-11-18 19:29:36 UTC
I only found this report now, I've added a comment in a F12 bug that was being closed. I'm experiencing the same problem, since F12.

Matej, will it help if I provide the info you requested as well or the files fropeter provided are enough?

This is a common bug since F12, I've seed more then a 10 of these reporting the same issue. It makes the computer unusable with KMS so I think it's quite important to fix this.

Comment 13 Jérôme Glisse 2010-11-19 14:27:12 UTC
Please 1 person 1 bug let us decide if things are duplicate we tend to completely ignore bug where everyone come up with its own story. tialaramex do you still have the issue ? What is your hardware (GPU, is this a laptop ?) ?

Others people please open a new bug against F14 after testing with F14, provide hw description, laptop model, GPU model ...

Comment 14 António Lima 2010-11-19 15:57:57 UTC
I'm sorry for the noise. Didn't what to file a possible duplicate bug. New bug report is bug #655101.

Thank you.

Comment 15 Matěj Cepl 2010-11-19 18:50:24 UTC
(In reply to comment #13)
> Please 1 person 1 bug let us decide if things are duplicate we tend to
> completely ignore bug where everyone come up with its own story. tialaramex do
> you still have the issue ? What is your hardware (GPU, is this a laptop ?) ?
> 
> Others people please open a new bug against F14 after testing with F14, provide
> hw description, laptop model, GPU model ...

and logs as requested in the comment 3, please.

Thank you

Comment 16 fropeter 2011-02-25 20:27:11 UTC
I just noticed:
I somehow had set 'nomodeset' on the boot command line in grub.conf. I don't know when, but I tried different drivers a while back. I haven't experienced the blank screens for a long time, but had other problems, such as faulty scrolling in text windows. I tried removing the 'nomodeset' entry, and the other problems vanished, but the screen blanking returned. I've had that happening two times the last few hours. The only remedy is to shut the lid, entering sleep state, and open it to recover. Then the display works again. On fedora 12 on a stationary machine I can press Alt-Ctrl-F2 to switch to a different virtual terminal, and Alt-Ctrl-F1 to return to the original screen,wich is now working. This does not work on F14 on my laptop. I wonder what to do on the stationary if I installed F14, shut the lid..?

I think the 'nomodeset' thing may be a clue; you decide.

Comment 17 Fedora End Of Life 2012-08-16 18:22:29 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping