Bug 500752 - Upgrade from 2.6.29.2 to 2.6.29.3 broke 'nomodeset' and locks up X on ATI Radeon Mobility M6 LV
Upgrade from 2.6.29.2 to 2.6.29.3 broke 'nomodeset' and locks up X on ATI Rad...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
11
i686 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-13 18:57 EDT by Nate
Modified: 2010-03-23 19:42 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-23 19:42:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
poor quality photos of image corruption (1.87 MB, application/x-bzip)
2009-05-13 18:57 EDT, Nate
no flags Details
Beter quality image of the corruption. (583.81 KB, image/jpeg)
2009-05-18 14:37 EDT, Nate
no flags Details
screenshots (NOT USING CAMERA) (7.19 MB, application/x-bzip)
2009-08-11 16:19 EDT, Ted
no flags Details

  None (edit)
Description Nate 2009-05-13 18:57:25 EDT
Created attachment 343881 [details]
poor quality photos of image corruption

Description of problem:


To related issues:

A) The modesetting on ATI Radeon Mobility M6 is causes image corruption if you use KMS. It's like your seeing double.. I'll attach photo to illistrate corruption.

Otherwise the display works correctly... correct color depth and resolution.

Using the 'nomodeset' option caused the display to work normally with no corruption, which brings me to this next point...


B) Going from the 2.6.29.2-126.fc11.i586 to the 2.6.29.3-140.fc11.i586 kernel causes X to lock up the hardware when using the 'nomodeset' option. 

Note that using KMS gets the same results as with 2.6.29.2... the screen works and mouse works, correct resolution and color depth, but the display is corrupted somewhat.

So the combination of this... the 'nomodeset' == crash and KMS causing screen corruption renders 2.6.29.3 kernel provided by Fedora worthless on this particular laptop. 


There is no xorg.conf or anything else like that. When the system locks up nothing gets recorded to xorg.0.log




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


kernel-2.6.29.2-126.fc11.i586
kernel-2.6.29.3-140.fc11.i586
xorg-x11-drv-ati-6.12.2-13.fc11.i586


How reproducible:

Very. 



Steps to Reproduce:
1. Install Fedora 11 beta (the screen corruption happens right off the bat, the nomodeset 'fix' is required.)
2. Upgrade to 2.6.29.2-126 kernel 
3. Upgrade to 2.6.29.3-140 kernel
4. Use KMS and see screen corruption on both kernels.
4, nomodeset option correctly works for 2.6.29.2-126 kernel when you reboot
5. nomodeset option crashes computer with 2.6.29.3-140

 
Actual results:

Choose between a corrupt display using KMS 
or 
older kernel and nomodeset


Expected results:

Upgraded kernel performs well with no regressions. KMS works without goobering up the display.


Additional info:


I appologize for the very lousy photographs. I don't have access to a camera right now so the best is my cell phone and it is not optimized for close up viewing. 

The images are a bit blurry, but the image is blurry-looking anyways.

I'll try to get a better shot.
Comment 1 Nate 2009-05-18 14:34:55 EDT
I attached a better screen shot.

The deal is that it appears that every other collumn of pixels is reversed.. that is if your looking a circle being rendered then the line will be broken up and in alternating places the curve will be going in the wrong direction.


Also we have found out that if you use KMS mode setting and have a external monitor hooked up then that external monitor will be the one displaying the corruption, while the LCD on the laptop looks correct. Then you can switch to the LCD and it will function correctly. 

So there is something weird with the initalization that causes the pixels to be reversed or whatever.
Comment 2 Nate 2009-05-18 14:37:04 EDT
Created attachment 344498 [details]
Beter quality image of the corruption.

better quality screen shot.
Comment 3 Bug Zapper 2009-06-09 11:47:41 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Ted 2009-08-11 16:19:09 EDT
Created attachment 357076 [details]
screenshots (NOT USING CAMERA)

this is really annoying me, so i'll try to give a couple of screenshots
I chose an image that it would be easy to "match up" to the original when distorted
Unfortunately, i do not have a camera, and had to use xwd. sorry.
the corruption has 3 columns of image, then one of transparency, tiled across the screen several times.
xwd draws the image in front, but it appears otherwise
I am using fedora 11, from net install (ftp insall.img) on ext4, with kms,
Linux F11 2.6.29.6-217.2.3.fc11.i586 #1 SMP Wed Jul 29 15:46:46 EDT 2009 i686 i686 i386 GNU/Linux
imo it is xorg-x11-drv-intel related
BTW do not reply, i don't come to bugzilla often (ever?)

idk why apps like gpicview,dillo,qemu,xterm fail, but qt4 and gtk ones don't

PS
just incase i return can someone tell me how to post a comment?
Comment 5 Ted 2009-08-11 16:32:03 EDT
Sorry, (Yes I found the box) but could a mod remove my attachment? The screen definitely doesn't look like that. Every 3 rows of rainbow would be a 2x height (6x scale) THIRD of the rainbow, (but the rotation is the same as the captured corruption). Each third is (top to bottom) laid left to right, followed by a blank space equal in width to each third. The third is half as long as the word at the end of this sentence. All the corruption has the correct darkness for its y coodinates.
Comment 6 Jérôme Glisse 2009-10-14 06:41:41 EDT
Can you test with fedora 12 livecd and report if it works with it.
Comment 7 Vedran Miletić 2010-03-23 19:42:39 EDT
Reporter doesn't reply for a long time. Closing.

If someone can still reproduce this with recent kernels, please reopen.

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