Bug 522271 - KMS:M76|RV630:HD2600 Fails to display (pll & fdiv)
KMS:M76|RV630:HD2600 Fails to display (pll & fdiv)
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Jérôme Glisse
Fedora Extras Quality Assurance
: Triaged
: 495294 522250 544018 (view as bug list)
Depends On: 444542
  Show dependency treegraph
Reported: 2009-09-09 18:58 EDT by Martin Ebourne
Modified: 2018-04-11 03:01 EDT (History)
5 users (show)

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

Attachments (Terms of Use)
Xorg.0.log from working nomodeset (77.21 KB, text/plain)
2009-11-10 17:07 EST, Martin Ebourne
no flags Details
M76 reg dump from working nomodeset (4.68 KB, text/plain)
2009-11-10 17:08 EST, Martin Ebourne
no flags Details
Reg dump from distorted screen with kms (4.66 KB, text/plain)
2009-11-10 17:10 EST, Martin Ebourne
no flags Details
Disable scaler if in native lcd resolution (2.85 KB, patch)
2009-11-12 07:20 EST, Jérôme Glisse
no flags Details | Diff
dmesg from drm.debug=15 boot (63.44 KB, text/plain)
2009-11-13 15:32 EST, Martin Ebourne
no flags Details
Patch with pll hack (444 bytes, text/plain)
2009-12-06 05:03 EST, Martin Ebourne
no flags Details

  None (edit)
Description Martin Ebourne 2009-09-09 18:58:23 EDT
+++ This bug was initially created as a clone of Bug #444542 +++

Description of problem:
Using Fedora 12 radeon test day live image X often fails to display on my laptop. If the machine has been powered off for a while it tends to display correctly and work, but otherwise (eg. after v-c switch, X restart, suspend-resume, reboot) it often fails to initialise the screen

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

How reproducible:
At least a quarter of the time.

Steps to Reproduce:
1. Boot machine from cold
2. If a working X display results restart X

Actual results:
LCD goes blank and then fills up with grey from the bottom taking a couple of
seconds. Ends in a light grey steady state with no visible picture.

Expected results:
Normal X display

Additional info:
I see this whether I use the default modesetting or disable modesetting, though obviously the latter is more common since it reprograms the video more often. With nomodeset sometimes switching to VC and back fixes the problem.

I've cloned this from a F9 bug I reported because it is exactly the same symptoms as I had then, and that bug resulted in a fix which might help track this one down.

See comments 6 and 7 on the original bug for the last fix:

See the attachments to bug #522250 for the various Xorg and dmesg logs both with and without modeset.
Comment 1 Jérôme Glisse 2009-10-21 17:12:36 EDT
Do you still have this issue with a more recent F12 (especialy kernel -XX > 65) ?
Comment 2 Martin Ebourne 2009-10-21 19:37:29 EDT
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?
Comment 3 Adam Williamson 2009-10-21 20:15:38 EDT
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
Comment 4 Martin Ebourne 2009-11-02 19:26:50 EST
Still broken on kernel- Have upgraded to rawhide so can easily test any ideas you have.
Comment 5 Adam Williamson 2009-11-02 19:44:39 EST
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
Comment 6 Matěj Cepl 2009-11-05 12:15:37 EST
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.]
Comment 7 Martin Ebourne 2009-11-05 16:28:31 EST
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.
Comment 8 Martin Ebourne 2009-11-05 16:38:11 EST
*** Bug 495294 has been marked as a duplicate of this bug. ***
Comment 9 Jérôme Glisse 2009-11-06 08:04:15 EST
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:

Comment 10 Jérôme Glisse 2009-11-06 08:07:25 EST
*** Bug 522250 has been marked as a duplicate of this bug. ***
Comment 11 Martin Ebourne 2009-11-08 06:31:46 EST
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.
Comment 12 Jérôme Glisse 2009-11-10 14:42:26 EST
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

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.
Comment 13 Martin Ebourne 2009-11-10 17:06:50 EST
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.
Comment 14 Martin Ebourne 2009-11-10 17:07:36 EST
Created attachment 368956 [details]
Xorg.0.log from working nomodeset
Comment 15 Martin Ebourne 2009-11-10 17:08:50 EST
Created attachment 368957 [details]
M76 reg dump from working nomodeset
Comment 16 Martin Ebourne 2009-11-10 17:10:50 EST
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)
Comment 17 Jérôme Glisse 2009-11-12 03:21:16 EST
The pitch difference is weird. You don't have any external monitor connected or virtual option in your xorg.conf ?
Comment 18 Martin Ebourne 2009-11-12 03:36:28 EST
There's no external display, only the laptop panel, and there's no xorg.conf either.
Comment 19 Jérôme Glisse 2009-11-12 06:37:14 EST
Please boot with drm.debug=15 and attach dmesg thanks.
Comment 20 Jérôme Glisse 2009-11-12 07:20:33 EST
Created attachment 369204 [details]
Disable scaler if in native lcd resolution

This patch apply on top of drm-next branch of airlied repo :

It disable scaler when using native resolution, it should do what the ddx is doing. Please test and report.
Comment 21 Martin Ebourne 2009-11-13 15:32:09 EST
Created attachment 369482 [details]
dmesg from drm.debug=15 boot
Comment 22 Martin Ebourne 2009-11-13 15:37:30 EST
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.
Comment 23 Martin Ebourne 2009-11-13 19:18:06 EST
Unfortunately the scaler patch hasn't worked. I applied it on kernel- 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
Comment 24 Bug Zapper 2009-11-16 07:09:28 EST
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:
Comment 25 Jérôme Glisse 2009-11-17 13:05:23 EST
Please try if lastest kernel -134 helps :
Comment 26 Martin Ebourne 2009-11-17 18:30:45 EST
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?
Comment 27 Jérôme Glisse 2009-12-04 09:59:14 EST
Which patch are you talking about ? Does -157 or above works ?
Comment 28 Martin Ebourne 2009-12-06 05:00:36 EST
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- 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.)
Comment 29 Martin Ebourne 2009-12-06 05:03:58 EST
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 :)
Comment 30 Matěj Cepl 2009-12-07 20:54:33 EST
*** Bug 544018 has been marked as a duplicate of this bug. ***
Comment 31 Jérôme Glisse 2010-01-22 09:56:51 EST
Martin please try (if you have the courage to build kernel by yourself) the lastest drm from :

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.
Comment 32 Martin Ebourne 2010-01-25 23:48:47 EST
Sure no problem. I rebased kernel- 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.
Comment 33 Jérôme Glisse 2010-03-11 10:58:11 EST
Can we assume it's now fixed ?
Comment 34 Leif Gruenwoldt 2010-03-11 12:25:07 EST
(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. 


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
Comment 35 Martin Ebourne 2010-03-21 21:57:03 EDT
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.
Comment 36 Leif Gruenwoldt 2010-03-22 11:52:16 EDT
(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?

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