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-ati | Assignee: | Jérôme Glisse <jglisse> | ||||||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||
| Severity: | high | Docs Contact: | |||||||||||||||
| Priority: | low | ||||||||||||||||
| Version: | 14 | CC: | 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
Nick Lamb
2010-04-14 14:12:03 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 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). 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. 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..
Created attachment 460700 [details]
/var/log/Xorg.0.log
Created attachment 460701 [details]
/var/log/Xorg.9.log
Created attachment 460702 [details]
output of dmesg command
Created attachment 460705 [details]
/var/log/messages
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.
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... ;-) Booted with drm.debug=0x04 on the kernel line in grub, provided all requested files. 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. 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 ... I'm sorry for the noise. Didn't what to file a possible duplicate bug. New bug report is bug #655101. Thank you. (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 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. 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 |