Bug 655101 - KMS:RV620:(lockup?) HD3400 LVDS random black screen with KMS enabled
Summary: KMS:RV620:(lockup?) HD3400 LVDS random black screen with KMS enabled
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 14
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jérôme Glisse
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-19 15:55 UTC by António Lima
Modified: 2012-08-16 18:25 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-08-16 18:25:25 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
lspci output (2.21 KB, text/plain)
2010-11-19 15:55 UTC, António Lima
no flags Details
lsusb output (590 bytes, text/plain)
2010-11-19 15:56 UTC, António Lima
no flags Details
xorg log (120.87 KB, text/plain)
2010-11-19 15:56 UTC, António Lima
no flags Details
xorg log with drm.debug=0x04 (92.45 KB, text/plain)
2010-11-19 19:03 UTC, António Lima
no flags Details
dmesg output with drm.debug=0x04 (109.85 KB, text/plain)
2010-11-19 19:04 UTC, António Lima
no flags Details
/var/log/messages with drm.debug=0x04 (1.40 MB, text/plain)
2010-11-19 19:07 UTC, António Lima
no flags Details
/var/log/messages after lockup (860.64 KB, text/plain)
2011-03-03 12:02 UTC, António Lima
no flags Details

Description António Lima 2010-11-19 15:55:14 UTC
Created attachment 461585 [details]
lspci output

Description of problem:

Randomly my screen gets totally dark although the backlight is on, like it would go to sleep but I could not wake it up. It's not possible to switch to a another VT and the only solution is reboot. This happens only with KMS enabled, and this problem has been present with this laptop in Fedora since F12. 


How reproducible:

There is not noticeable chain of events to reproduce the bug, it appears to be random. 

Additional info:

This is a toshiba satellite laptop with a ATI Radeon HD3400. I'm attaching the output of lspci, lsusb and Xorg log. I'm not using a xorg.conf file, so the driver should be the default radeon.


I tried to install mesa-dri-drivers-experimental and I'm running with them for almost a day with no lockup. This is still very inconclusive since I don't now if this package contains any changes that can affect this bug and sometimes the lockups can take several hours to happen.

Comment 1 António Lima 2010-11-19 15:56:10 UTC
Created attachment 461587 [details]
lsusb output

Comment 2 António Lima 2010-11-19 15:56:38 UTC
Created attachment 461588 [details]
xorg log

Comment 3 António Lima 2010-11-19 19:03:39 UTC
Created attachment 461624 [details]
xorg log with drm.debug=0x04

Comment 4 António Lima 2010-11-19 19:04:36 UTC
Created attachment 461625 [details]
dmesg output with drm.debug=0x04

Comment 5 António Lima 2010-11-19 19:07:11 UTC
Created attachment 461627 [details]
/var/log/messages with drm.debug=0x04

As requested in https://bugzilla.redhat.com/show_bug.cgi?id=582264#c15 here are the requested files with drm.debug=0x04 .

Please let me know if I can provide further information.

Thanks!

Comment 6 Jérôme Glisse 2010-11-19 19:27:09 UTC
Do you still experience the issue when booting with radeon.dynclks=0 ?

Comment 7 António Lima 2010-11-19 19:38:56 UTC
I'll reboot with radeon.dynclks=0 argument and get back to you as soon as I have results. Since the issue can take several hours to happen, I'll wait until I have 2 days of use without the lockups to consider that this argument solves the problem.

Thanks Jerome.

Comment 8 António Lima 2010-11-20 12:20:36 UTC
I'm afraid radeon.dynclks=0 didn't solve the problem. I just had a lockup. They seem less frequent then in previous releases.

As a side note, although I have power management preferences set to suspend the laptop when I close it, when I got the lockup it did not suspend.

Comment 9 Jérôme Glisse 2010-11-23 17:02:24 UTC
So you can't ssh to the laptop when the screen goes black ? What are you doing at time of blackscreen ? Firefox ? Games ? 3D application ? Screensaver ?

If this is a lockup there is little we can do.

Comment 10 António Lima 2010-11-23 17:17:36 UTC
I won't be able to ssh when the screen goes black for a few days but will try to as soon I get my other pc back.

The black screen appears when I'm doing ordinary stuff like email and web browsing with firefox.

If this is KMS related I could try to install a more recent kernel but since this bug has been around for me since KMS came along I have little hope...

Comment 11 Alick Zhao 2010-12-07 03:21:54 UTC
My laptop is HP 6531s with ATI Mobility Radeon HD3430, and I experience the same situation as António -- lockup after random time. When I boot with arg `nomodeset' this problem don't happen. So I think it is a KMS issue.

Comment 12 António Lima 2011-03-03 12:02:17 UTC
Created attachment 482053 [details]
/var/log/messages after lockup

Finally I can manage to suspend the laptop by closing the lid when a black screen appears. Probably with some update to the kernel, since for several months I've been using nomodeset.

When I resume the computer comes back to life. I see suspicious lines in /var/log/messages. 

Mar  3 10:44:31 Gert rtkit-daemon[1749]: Recovering from system lockup, not allowing further RT threads.

Hope this can bring some light to this bug. My worries is that with the upcoming F15 I will still have this bug and not be able to use gnome-shell since it does not run with nomodeset, at least with this radeon driver.

Comment 13 Alick Zhao 2011-12-04 06:48:34 UTC
Now I got my OS upgraded to Fedora 16. It seems fine with the default KMS setting.

Comment 14 Fedora End Of Life 2012-08-16 18:25:27 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


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