Bug 582726

Created attachment 406976 [details]
lspci -nnn -vvv

lspci from F12/nomodeset

Please attach a screenshot or a picture of the issue also full dmesg and full xorg log.

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)

any progress at all on this?

(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.

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.

Greetings
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.

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.

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]
Backtrace:
[   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.

This bug is about radeon driver, not nvidia.. and corruption looks very different.
I think they're different issues

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.

Fresh xorg (in updates tree since a few days ago) indeed causes corruption, but gives me a problem even with nomodeset
https://bugzilla.redhat.com/show_bug.cgi?id=609280

Please raise priority on this. I'm about to lose UMS support for this laptop, and KMS is still not usable!

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.

The issue is gone when using that option.

Will there be a fix for this in the [near] future? Or should I expect having to use this option for years to come?

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.

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.

Just happened again. This had better not turn into a daily occurrence

This is still happening once a week, forcing me to reboot. Please check and fix if possible!

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Running Fedora 14 and still forced to use radeon.new_pll=0 workaround

Upgraded to Fedora 16. Not using radeon.new_pll=0, everything seems working
Better close the bug

wow, nobody can even be bothered to close the bug