Do you still have this issue with a more recent F12 (especialy kernel -XX > 65) ?

Just tried F12 beta live CD, same result. Should this be an F12 blocker since the livecd is pretty much useless on this hardware? (I doubt a proper install would be any better either.)

Does the F9 bug I linked to before help? The old bug had the same symptoms on the same laptop and the refdiv build in comment 6 fixed it so maybe something regressed? Otherwise how can I help debug this?

the Beta doesn't have a recent enough kernel, it has -56. You can grab a later build from Koji - http://koji.fedoraproject.org/koji/buildinfo?buildID=137561 is the latest build at time of writing.

unfortunately we're still not yet at the point where we can consider single-chipset X issues release blockers, even serious ones :/ we will do our best to resolve as many as possible before release, however.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Still broken on kernel-2.6.31.5-110.fc12.x86_64. Have upgraded to rawhide so can easily test any ideas you have.

Thanks for testing. The Radeon developers are rather tied up with 528593 at present, but hopefully they'll have time to take a look at this one too.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

As per comment 3 days ago this is very much a current bug and makes suspend with KMS unusable on this hardware. This also affects non-KMS as well, any vt-switch, suspend, etc causes this about 80% of the time.

Sometimes the display fills with grey from the left, sometimes it gets a range of colours.

This hardware worked fine on Fedora 9/10. Last time I checked it worked fine with radeonhd non-KMS too.

Just retested with latest rawhide + koji kernel, still broken.
xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12.x86_64
kernel-2.6.31.5-122.fc12.x86_64

*** Bug 495294 has been marked as a duplicate of this bug. ***

DDX commit 592bcac52f113a95923a8f1cb8427e7552d5670b has reversed this, KMS code thus as the same code as the DDX, i am trying to find out what we should do. As 
592bcac52f113a95923a8f1cb8427e7552d5670b was done to fix:

http://bugs.freedesktop.org/show_bug.cgi?id=20458

*** Bug 522250 has been marked as a duplicate of this bug. ***

I've reverted DDX 592bcac52f113a95923a8f1cb8427e7552d5670b from xorg-x11-drv-ati and can confirm that has completely fixed the problem with the screen filling with white, so you're definitely on the right track. nomodeset is now working well on this laptop which is really great since I was having to reboot it constantly - thanks for finding that!

I also made a similar change to the kernel to force RADEON_PLL_USE_REF_DIV on. This has fixed the same issue with KMS active so the screen doesn't fill with white. Slightly surprisingly it also fixed the nomodeset case even without the xorg-x11-drv-ati installed, I guess the code must be used for VT switch in both cases?

I should note that the kernel hack didn't fix the display corruption and flickering in bug 522250 which was marked as a duplicate of this one. I'm still unsure that's really a duplicate if this one has a fix which makes no difference to bug 522250 at all.

Martin i will need you to dump some registers for me. Please do:
sudo yum install libpciaccess-devel
git clone git://anongit.freedesktop.org/~airlied/radeontool
cd radeontool
make

Then with working nonmodeset :
sudo ./avivotool regmatch * > m76-working
Then with kms broken (i guess you will need to login through ssh from a different computer to do that) :
sudo ./avivotool regmatch * > m76-broken

And attach both file to the bug, also please attach Xorg.log with nomodeset working configuration. Thanks.

Jerome I'm assuming you are after the registers with the display distortion I get on kms but not old xorg, was originally in the other bug. I can still use the machine locally for debugging but not for serious work since the display is distorted like in the screenshots I attached before: https://bugzilla.redhat.com/attachment.cgi?id=360357

Handy tool you have there. This fixes the display completely:
# ./avivotool regset AVIVO_D1SCL_SCALER_ENABLE 0x00000000
OLD: AVIVO_D1SCL_SCALER_ENABLE (6590)   0x00000001 (1)
NEW: AVIVO_D1SCL_SCALER_ENABLE (6590)   0x00000000 (0)

Switching the scalar on and off controls the distortion. It needs to be disabled again after suspend/resume of course. Can confirm with the scalar off everything is working great, thanks!

I'll attach the other info you asked for as well, quite a few reg differences there that might be useful.

If you wanted me to get a reg dump from the white screen problem that RADEON_PLL_USE_REF_DIV fixes let me know and I'll get that too.

Created attachment 368956 [details]
Xorg.0.log from working nomodeset

Created attachment 368957 [details]
M76 reg dump from working nomodeset

Created attachment 368958 [details]
Reg dump from distorted screen with kms

The reg diffs from working to broken:

--- m76-working 2009-11-10 21:44:16.000000000 +0000
+++ m76-broken  2009-11-10 21:48:39.000000000 +0000
@@ -19,3 +19,3 @@
-AVIVO_D1GRPH_PRIMARY_SURFACE_ADDRESS (6110)    0xd0000000 (-805306368)
-AVIVO_D1GRPH_SECONDARY_SURFACE_ADDRESS (6118)  0xd0000000 (-805306368)
-AVIVO_D1GRPH_PITCH (6120)      0x00000f00 (3840)
+AVIVO_D1GRPH_PRIMARY_SURFACE_ADDRESS (6110)    0xd0a13000 (-794742784)
+AVIVO_D1GRPH_SECONDARY_SURFACE_ADDRESS (6118)  0xd0a13000 (-794742784)
+AVIVO_D1GRPH_PITCH (6120)      0x00000800 (2048)
@@ -24,2 +24,2 @@
-AVIVO_D1GRPH_X_END (6134)      0x00000f00 (3840)
-AVIVO_D1GRPH_Y_END (6138)      0x00000780 (1920)
+AVIVO_D1GRPH_X_END (6134)      0x00000780 (1920)
+AVIVO_D1GRPH_Y_END (6138)      0x000004b0 (1200)
@@ -30 +30 @@
-AVIVO_D1SCL_SCALER_ENABLE (6590)       0x00000000 (0)
+AVIVO_D1SCL_SCALER_ENABLE (6590)       0x00000001 (1)
@@ -49 +49 @@
-AVIVO_D2GRPH_CONTROL (6904)    0x00100002 (1048578)
+AVIVO_D2GRPH_CONTROL (6904)    0x00000002 (2)
@@ -52 +52 @@
-AVIVO_D2GRPH_PITCH (6920)      0x00000640 (1600)
+AVIVO_D2GRPH_PITCH (6920)      0x00000500 (1280)
@@ -55,2 +55,2 @@
-AVIVO_D2GRPH_X_END (6934)      0x00000640 (1600)
-AVIVO_D2GRPH_Y_END (6938)      0x000004b0 (1200)
+AVIVO_D2GRPH_X_END (6934)      0x00000500 (1280)
+AVIVO_D2GRPH_Y_END (6938)      0x00000300 (768)
@@ -60 +60 @@
-AVIVO_D2MODE_VIEWPORT_SIZE (6d84)      0x064004b0 (104858800)
+AVIVO_D2MODE_VIEWPORT_SIZE (6d84)      0x00000000 (0)
@@ -85,3 +85,3 @@
-AVIVO_D1CUR_CONTROL (6400)     0x00000200 (512)
-AVIVO_D1CUR_POSITION (6414)    0x02060104 (33947908)
-AVIVO_D1CUR_SURFACE_ADDRESS (6408)     0xd1c20000 (-775815168)
+AVIVO_D1CUR_CONTROL (6400)     0x00000201 (513)
+AVIVO_D1CUR_POSITION (6414)    0x04c70238 (80151096)
+AVIVO_D1CUR_SURFACE_ADDRESS (6408)     0xd0a0b000 (-794775552)
@@ -90 +90 @@
-AVIVO_D2VGA_CONTROL (0338)     0x00000400 (1024)
+AVIVO_D2VGA_CONTROL (0338)     0x00000000 (0)

The pitch difference is weird. You don't have any external monitor connected or virtual option in your xorg.conf ?

There's no external display, only the laptop panel, and there's no xorg.conf either.

Please boot with drm.debug=15 and attach dmesg thanks.

Created attachment 369204 [details]
Disable scaler if in native lcd resolution

This patch apply on top of drm-next branch of airlied repo :
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git

It disable scaler when using native resolution, it should do what the ddx is doing. Please test and report.

Created attachment 369482 [details]
dmesg from drm.debug=15 boot

As an aside, is the dpi supposed to work with kms?

I'm getting this from xdpyinfo and the fonts as a result are scaled wrong:

  dimensions:    1920x1200 pixels (508x317 millimeters)
  resolution:    96x96 dots per inch

The correct dpi for this screen is 147 as it's a 15" widescreen laptop, it's certainly not 0.5m wide.

Unfortunately the scaler patch hasn't worked. I applied it on kernel-2.6.31.5-127.fc12.x86_64 resulting in:

- On bootup the screen is set correctly and everything seems fine, this was not the case before
- Near the end of the boot sequence the screen goes black and then reappears with the scaler problem as before. Before the patch the screen did not black at all during the plymouth boot
- On resume from suspend the scaler problem is there again

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Please try if lastest kernel -134 helps :
http://koji.fedoraproject.org/koji/buildinfo?buildID=141560

Yes that appears to fix the display corruption (scaler) issue. The pll ref div is still broken, until I rebuild with that patch I can't be totally certain on the scaler fix (wasn't able to test suspend/resume).

Also I get new breakage on the 3D which was working great but is now failing with 

[drm:r600_cs_packet_next_reloc_mm] *ERROR* No packet3 for relocation for packet at 47.
[drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

Do I need to upgrade mesa or similar for that?

Which patch are you talking about ? Does -157 or above works ?

There are two separate issues in this bug. The scalar problem causing a stretched/distorted display was originally bug 522250. I believe this is completely fixed in recent kernel builds (I'm using kernel-2.6.31.6-162.fc12.x86_64 at the moment which works well including suspend/resume).

The original issue reported in this bug (and diagnosed in comment #9), the screen filling up with grey and not displaying at all, is still not fixed as far as I know. I build it with a hack to force RADEON_PLL_USE_REF_DIV on as per comment #11, then it works. Is there a proper fix available for this yet? (Also affects non-kms.)

Created attachment 376423 [details]
Patch with pll hack

This patch is my hack to force RADEON_PLL_USE_REF_DIV on. Not suitable for upstream :)

*** Bug 544018 has been marked as a duplicate of this bug. ***

Martin please try (if you have the courage to build kernel by yourself) the lastest drm from :
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-testing

git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
cd drm-2.6
git branch drm-radeon-testing origin/drm-radeon-testing
git checkout -f drm-radeon-testing

Then use normal procedure to build your kernel.

Sure no problem. I rebased kernel-2.6.31.6-162.fc12.x86_64 off your tree, dropping the upstream patches. Running it now and is working well so far thanks. Problem was intermittent but frequent, if it comes back I'll comment here.

Can we assume it's now fixed ?

(In reply to comment #33)
> Can we assume it's now fixed ?    

I just tried Fedora13 alpha and my DVI monitor still does not light up. Nor does it work with latest from Fedora 12. 

kernel-2.6.33-0.52.rc8.git6.fc13.x86_64
xorg-x11-drv-ati-6.13.0-0.22.20100208git4f9d1714a.fc13.x86_64

I believe the last time it worked was in Fedora11.

My work around was to use the VGA connector but now that has problems too, Bug #571874

Jerome, the drm-radeon-testing tree worked great. I've upgraded now to the F13 alpha release and using the stock kernel this hardware now seems to be working fully. Thanks very much for your help.

Leif, given that this bug was about a non-working built in display on my HP laptop, which is now working, I think you should raise a new bug for your problem since it is a different issue.

(In reply to comment #35)
> Leif, given that this bug was about a non-working built in display on my HP
> laptop, which is now working, I think you should raise a new bug for your
> problem since it is a different issue.    

My bug (bug #544018) got marked as a duplicate of this one by one of the redhat devs, Matej Cepl. Jerome are you satisfied with me reopening that bug and keeping this one closed?