Bug 582726 - KMS:RV515:M54:X1400 screen corruption every few seconds
KMS:RV515:M54:X1400 screen corruption every few seconds
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Jerome Glisse
Fedora Extras Quality Assurance
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2010-04-15 12:28 EDT by Konstantin Svist
Modified: 2011-12-15 17:19 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-12-15 17:19:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
lspci -nnn -vvv (1.73 KB, text/plain)
2010-04-15 22:42 EDT, Konstantin Svist
no flags Details
photo of the problem (2.37 MB, image/jpeg)
2010-04-22 17:47 EDT, Konstantin Svist
no flags Details
Xorg.0.log, messages, xorg.conf.d, dmesg (37.13 KB, application/x-bzip2)
2010-06-28 17:51 EDT, Konstantin Svist
no flags Details
Screenshot showing screen corruption (6.97 MB, image/png)
2010-06-30 22:28 EDT, Yaakoub El Khamra
no flags Details

  None (edit)
Description Konstantin Svist 2010-04-15 12:28:36 EDT
Description of problem:
If booted without nomodeset, the screen gets corrupted every few seconds:
* the image becomes frozen
* pixel-sized checkerboard pattern (or corruption?) appears on top of the image
* some parts of the screen are also corrupted with short horizontal lines
* color bleed appears starting from the corners of the screen moving toward the center.
* after 1-5 seconds of this, the screen becomes restored to normal

Version-Release number of selected component (if applicable):

How reproducible:
almost every time
If the problem appears once during a boot session, it happens every few (~10-15) seconds. Rarely, though, the problem doesn't appear.

Steps to Reproduce:
1. boot with KMS enabled
Actual results:

Expected results:

Additional info:
Comment 1 Konstantin Svist 2010-04-15 22:42:08 EDT
Created attachment 406976 [details]
lspci -nnn -vvv

lspci from F12/nomodeset
Comment 2 Jerome Glisse 2010-04-19 02:56:55 EDT
Please attach a screenshot or a picture of the issue also full dmesg and full xorg log.
Comment 3 Konstantin Svist 2010-04-22 17:47:30 EDT
Created attachment 408455 [details]
photo of the problem

Screenshots always come out pristine, not a pixel out of place. Attached photo shows what I see.

I've uploaded a few videos of bug in action to youtube:
http://www.youtube.com/watch?v=mfKweKiiCY4 (closeup)
http://www.youtube.com/watch?v=5vquemNQiBs (closeup)
http://www.youtube.com/watch?v=oqkRH6Q3OSw (whole screen)
Comment 4 Konstantin Svist 2010-06-28 13:13:41 EDT
any progress at all on this?
Comment 5 Matěj Cepl 2010-06-28 17:00:42 EDT
(In reply to comment #2)
> Please attach a screenshot or a picture of the issue also full dmesg and full
> xorg log.    

We've got nice youtube movies, but we need those logs as well.

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 6 Konstantin Svist 2010-06-28 17:51:52 EDT
Created attachment 427518 [details]
Xorg.0.log, messages, xorg.conf.d, dmesg

Here you go.
In this boot, the login screen had the problem, but as soon as I logged in, everything looks okay. I have not tested it extensively today, but don't think it's an indicator of anything.
Comment 7 Yaakoub El Khamra 2010-06-30 22:25:53 EDT
I can confirm I also run into this problem with my nvidia setup. I have xinerama enabled but the symptoms are pretty much the same. The corruption starts around the cursor and takes the form of a series of squares that follow it around.

Some of the time if I leave it alone for a while I get the screen back, sometimes it locks up pretty hard but I have noticed that this occurs while vbetool is punishing one of my processors at 100%.

Attached is a screenshot.
Comment 8 Yaakoub El Khamra 2010-06-30 22:28:30 EDT
Created attachment 428151 [details]
Screenshot showing screen corruption

The offending screen is the middle screen on the bottom row. I have a 3x30" screens on the bottom and 2x20" screens on top. The middle 30" screen is the only one that exhibits this behavior. Switching screens, dvi-d outlets etc... did not help.
Comment 9 Yaakoub El Khamra 2010-06-30 22:53:08 EDT
Please note I did upgrade to the latest xorg to fix the xinerama bug, but I had to disable SELinux to stop getting a hard lock or corruption when I get this message from X:

[    67.501] (EE) No input driver/identifier specified (ignoring)
[   607.304] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[   607.306]
[   607.426] 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x462518]
[   607.426] 1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x4a1e24]
[   607.426] 2: /usr/bin/Xorg (xf86PostMotionEventP+0xc4) [0x4808a4]
[   607.426] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f66fbc40000+0x3dbf) [0x7f66fbc43dbf]
[   607.426] 4: /usr/bin/Xorg (0x400000+0x6e657) [0x46e657]
[   607.426] 5: /usr/bin/Xorg (0x400000+0x10f723) [0x50f723]
[   607.426] 6: /lib64/libc.so.6 (0x3f32000000+0x32a20) [0x3f32032a20]
[   607.427] 7: /lib64/libc.so.6 (memcpy+0x2b0) [0x3f32083fc0]
[   607.427] 8: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7f66fc7b8000+0xc0505) [0x7f66fc878505]
[   607.427] 9: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7f66fc7b8000+0x37b6fc) [0x7f66fcb336fc]
[   607.427] 10: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7f66fc7b8000+0x37b912) [0x7f66fcb33912]
[   607.427] 11: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7f66fc7b8000+0x376396) [0x7f66fcb2e396]
[   607.427] 12: /usr/bin/Xorg (0x400000+0xcdfda) [0x4cdfda]
[   607.427] 13: /usr/bin/Xorg (0x400000+0xaf2ab) [0x4af2ab]
[   607.427] 14: /usr/bin/Xorg (ValidateGC+0x24) [0x442214]
[   607.427] 15: /usr/bin/Xorg (0x400000+0x3a588) [0x43a588]
[   607.427] 16: /usr/bin/Xorg (0x400000+0x158801) [0x558801]
[   607.427] 17: /usr/bin/Xorg (0x400000+0x3c66c) [0x43c66c]
[   607.427] 18: /usr/bin/Xorg (0x400000+0x219ca) [0x4219ca]
[   607.427] 19: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x3f3201ec5d]
[   607.427] 20: /usr/bin/Xorg (0x400000+0x21579) [0x421579]

Also, I am booting with these kernel options:
rdblacklist=nouveau pci=nommconf  intel_iommu=off nomodeset  acpi=off noacpi

The ACPI thing I suspect was making vbetool use 100% of one of my cores. NVRM complains that I do not have ACPI but I am running xeons on a workstation so it does not matter, the frequencies do not scale.
Comment 10 Konstantin Svist 2010-07-01 01:53:33 EDT
This bug is about radeon driver, not nvidia.. and corruption looks very different.
I think they're different issues
Comment 11 Yaakoub El Khamra 2010-07-01 02:22:15 EDT
I suspect it both are symptoms/manifestations of an underlying X issue. I tried the nouveau drivers, pretty much the same deal: corruption with squares on the middle screen. I genuinely hope I am wrong about this though as I have just updated my installation and there's a new xinput and so far things are going well.
Comment 12 Konstantin Svist 2010-07-01 03:59:28 EDT
Fresh xorg (in updates tree since a few days ago) indeed causes corruption, but gives me a problem even with nomodeset
Comment 13 Konstantin Svist 2010-07-08 12:47:45 EDT
Please raise priority on this. I'm about to lose UMS support for this laptop, and KMS is still not usable!
Comment 14 Jerome Glisse 2010-07-08 13:11:53 EDT
Yaakoub you have a different issue, you can open your own bug.

Konstantin can you add radeon.new_pll=0 to your kernel boot command line and see if you still experience the issue.
Comment 15 Konstantin Svist 2010-07-08 14:03:09 EDT
The issue is gone when using that option.
Comment 16 Konstantin Svist 2010-07-13 20:06:40 EDT
Will there be a fix for this in the [near] future? Or should I expect having to use this option for years to come?
Comment 17 Konstantin Svist 2010-07-20 15:42:17 EDT
Just got a similar issue. Same pixel-sized chekerboard pattern corruption, but disappears instantly, making it look like the brightness changed for a split second.
I'm fairly certain it'll go away after a reboot, since I haven't made any big changes to the system recently and it has behaved for almost 2 weeks.
Comment 18 Konstantin Svist 2010-07-20 15:59:12 EDT
Clarification: this is still with radeon.new_pll=0
Restarting X with ctrl+alt+bksp didn't affect the problem - it kept blinking. Rebooting the machine worked.
Comment 19 Konstantin Svist 2010-07-21 15:33:02 EDT
Just happened again. This had better not turn into a daily occurrence
Comment 20 Konstantin Svist 2010-09-02 00:17:01 EDT
This is still happening once a week, forcing me to reboot. Please check and fix if possible!
Comment 21 Bug Zapper 2011-06-02 11:18:25 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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: 
Comment 22 Konstantin Svist 2011-06-02 14:28:59 EDT
Running Fedora 14 and still forced to use radeon.new_pll=0 workaround
Comment 23 Konstantin Svist 2011-11-30 14:03:17 EST
Upgraded to Fedora 16. Not using radeon.new_pll=0, everything seems working
Better close the bug
Comment 24 Konstantin Svist 2011-12-15 17:19:33 EST
wow, nobody can even be bothered to close the bug

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