Bug 26552

Summary: Screen flickering with 2.6.37 [ATI X1600]
Product: Drivers Reporter: Andrea Iob (andrea_iob)
Component: Video(DRI - non Intel)Assignee: drivers_video-dri
Status: CLOSED CODE_FIX    
Severity: normal CC: alexdeucher, florian, hdasch, helbermg, kernel, kernelbugzilla, maciej.rutecki, rjw, thierry.vignaud
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.37 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 21782    
Attachments: dmesg when flickering is present
dmesg when there is no flickering
lspci -v
vbios
possible fix
alternate patch
combined patch
new consolidated patch
possible fix
new patch
final patch

Description Andrea Iob 2011-01-11 22:53:58 UTC
Created attachment 43282 [details]
dmesg when flickering is present

Starting from 2.6.37 the screen on my Toshiba Satellite A100 flickers as soon as kernel modesetting is initialized. The flickering does not occur always: sometimes the screen is almost unreadable, sometimes there is no flickering at all.

With 2.6.36 (and previous versions) I've never experienced flickering problems.
Comment 1 Andrea Iob 2011-01-11 22:54:49 UTC
Created attachment 43292 [details]
dmesg when there is no flickering
Comment 2 Daniel 2011-01-12 15:14:11 UTC
I have a "flicker" problem, too. While option radeon.new_pll=0 fixes the problem at kernel 2.6.35 and 2.6.36, now with 2.6.37 this option is gone. 

But my computer NOT starts directly flickering after kernel modesetting is initialized. It starts after performing some cpu usage like compiling. First there are many white lines flickering at the screen, then the screen going black.

Flickering Video: http://youtu.be/oKsQ4Ga1pKA

I have IBM Thinkpad T60 / Gentoo Linux
with ATI Technologies Inc Radeon Mobility X1400

Same problem? https://bugs.freedesktop.org/show_bug.cgi?id=32556
Comment 3 Alex Deucher 2011-01-12 17:18:43 UTC
I think this is probably a duplicate of bug 26562.

new_pll=0 became the default in 2.6.37.
Comment 4 Daniel 2011-01-12 18:28:41 UTC
Okay, but without new_pll=0 in 2.6.35/36 i had the completely identical error. Sombody else has this flickering white lines, before screen going black? (see video)
Comment 5 Andrea Iob 2011-01-12 22:03:07 UTC
(In reply to comment #2)
> 
> Same problem? https://bugs.freedesktop.org/show_bug.cgi?id=32556

I've tried the patches proposed in that bugreport (comment #24) without any luck: the flickering is still there.
Comment 6 Andrea Iob 2011-01-12 22:04:23 UTC
Created attachment 43332 [details]
lspci -v
Comment 7 Andrea Iob 2011-01-12 22:08:27 UTC
Created attachment 43342 [details]
vbios
Comment 8 Alex Deucher 2011-01-13 01:01:54 UTC
Created attachment 43362 [details]
possible fix

Does this patch fix the issues?
Comment 9 Daniel 2011-01-13 12:47:17 UTC
Hey Alex, this patch decrease the white-line flickering a lot and i had no more blank screen. The white lines you can see here: http://picpaste.com/flicker.jpg
Comment 10 Alex Deucher 2011-01-13 16:54:22 UTC
In addition to the patch does booting with:
radeon.disp_priority=2
on the kernel command line in grub help?

Additionally you can try these patches individually and see if any of them help?

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index 46178f9..50b4ef4 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -521,6 +521,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
        pll->flags = 0;
 
        if (ASIC_IS_AVIVO(rdev)) {
+               pll->flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
                if ((rdev->family == CHIP_RS600) ||
                    (rdev->family == CHIP_RS690) ||
                    (rdev->family == CHIP_RS740))

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index 46178f9..24aa984 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -521,6 +521,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
        pll->flags = 0;
 
        if (ASIC_IS_AVIVO(rdev)) {
+               pll->flags |= (RADEON_PLL_PREFER_MINM_OVER_MAXP |
+                              RADEON_PLL_USE_FRAC_FB_DIV);
                if ((rdev->family == CHIP_RS600) ||
                    (rdev->family == CHIP_RS690) ||
                    (rdev->family == CHIP_RS740))

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index 46178f9..fa8b96a 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -521,6 +521,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
        pll->flags = 0;
 
        if (ASIC_IS_AVIVO(rdev)) {
+               pll->flags |= RADEON_PLL_USE_FRAC_FB_DIV;
                if ((rdev->family == CHIP_RS600) ||
                    (rdev->family == CHIP_RS690) ||
                    (rdev->family == CHIP_RS740))
Comment 11 Alex Deucher 2011-01-13 17:34:20 UTC
Created attachment 43432 [details]
alternate patch

Can you try this patch as well instead of the patch in comment 8?
Comment 12 Andrea Iob 2011-01-13 20:26:04 UTC
Both patch of comment #8 and patch of comment #11 fix my problem. 

Thanks for your time.
Comment 13 Daniel 2011-01-13 22:16:24 UTC
With patch of comment #8 i had decrease flickering (as i said in comment #9) or after some reboots, flickering was completly gone. With patch of comment #8 AND radeon.disp_priority=2 i had lot of flickering and black screens.

With the changed for-loop of comment #11 it seems to be stable fix my problem. My current kernel command line: radeon.modeset=1 radeon.agpmode=-1 radeon.dynclks=1. I will made some tests and give you a response the next 1-2 days here. Thank you!
Comment 14 Andrea Iob 2011-01-15 14:06:50 UTC
I've spoken too soon, patch of comment #11 did NOT fix the problem. After at least 10 reboots without any problems, today the flickering is back. 

Now I'm back with patch of comment #8. After a couple of reboots all seems ok, I'll wait some days to see if the problem comes back again.
Comment 15 Daniel 2011-01-16 21:45:10 UTC
I made many tests last days with my Thinkpad T60 (Radeon Mobility X1400). Such as many reboots with ac-adapter and on battery only. Heavy cpu load for an hour and normal working the system the hole day. Attach an external monitor and switching the resolutions.

Comment #11 fix my problem and works stable for me.
Comment 16 Alex Deucher 2011-01-17 16:06:19 UTC
@Daniel, does the patch from comment 8 also work?  How about the patch in comment 8 plus some one of the mini-patches in comment 10?
Comment 17 Alex Deucher 2011-01-17 18:06:49 UTC
@Andrea, can you try the mini-patches in comment 10 along with the patch in comment 8 and report back which if there are any problems with any of them on your system?
Comment 18 Daniel 2011-01-18 18:56:33 UTC
Alex: As i said in comment #13, patch of comment #8 not fix my problem. I tested it again with same result. At the moment i test patch of comment #8 PLUS some one of the mini-patches in comment 10. I will report soon...
Comment 19 Andrea Iob 2011-01-18 21:44:25 UTC
These are the results of may tests:

- patch in comment #8 alone : ok

- patch in comment #8 + first patch in comment #10: ok

- patch in comment #8 + second patch in comment #10: flickering

- patch in comment #8 + third patch in comment #10: flickering
Comment 20 Daniel 2011-01-19 12:16:34 UTC
My results after tests since yesterday:
- patch in #8 + first patch in #10: ok
- patch in #8 + second patch in #10: ok
- patch in #8 + third patch in #10: flickering

For today i would test patch in comment #20.
Comment 21 Daniel 2011-01-19 21:14:55 UTC
After running with patch of comment #20 for 6 hours and no flickering, i suddenly got a black screen after watching a video for some minutes. Switching to tty1 and back to tty7 (xorg) the problem was gone for one minute and i got a black screen again. I watched the video again, but the problem was not reproducible. For now i rebooted and will try to verifying it again.
Comment 22 Daniel 2011-01-19 22:28:21 UTC
Oh, while some reboots one time it begins flickering directly after kms switching on console. I think patch of #20 is not stable for me. What can i do/test now?
Comment 23 Alex Deucher 2011-01-19 22:30:11 UTC
(In reply to comment #23)
> Oh, while some reboots one time it begins flickering directly after kms
> switching on console. I think patch of #20 is not stable for me. What can i
> do/test now?

Can you test the mini patches from comment 10 in combination with the patch from comment 20?
Comment 24 Andrea Iob 2011-01-21 19:49:07 UTC
Up to now (5 reboots), with patch in comment 8 plus patch in comment 20 there is NO flickering.
Comment 25 Daniel 2011-01-21 23:54:43 UTC
I tested the patch of #20 on top of #8 plus the mini patches from #10. With the third patch of #10 i had a black screen after some hours working yesterday. The screen was back, after i closed and opened the laptop display. Today morning with the first patch of #10, i had a black screen after 30min uptime. Close+opening the display and the screen was back and stable during the day. Now i compiled the kernel module with second patch of #10. I will reporting soon.
Comment 26 Daniel 2011-01-21 23:57:26 UTC
Sorry for the second post, i've forgotten: I had no more white line flickering!
Comment 27 Daniel 2011-01-24 12:56:04 UTC
Okay Alex, the patch of #20 on top of #8 plus the second mini patch from #10 seems to be stable for me. The last days i had no more flickering and no black screens.
Comment 28 Alex Deucher 2011-01-24 23:01:47 UTC
Created attachment 45032 [details]
combined patch

I think I've fixed everything.  Can you try this last patch by itself and make sure all is working properly?  If you have any external monitors, can you test them too?  I've tested this on all the hw I have an all seems well.
Comment 29 Daniel 2011-01-27 13:58:50 UTC
I tested the combined patch of #29 the last days. Two times the screen going black after compiling something and watching a video together. I remember at the beginning of this problem, the screen starts to flickering earlier, when i doing some cpu working things (see comment #2). How can I debug this for help you fixing this? Thanks.
Comment 30 Alex Deucher 2011-01-27 17:50:35 UTC
Created attachment 45272 [details]
new consolidated patch

It's probably just easier to stick with the old algo for rv515.  Try this patch out.
Comment 31 Daniel 2011-01-31 19:26:22 UTC
It seems to work fine for me. Since last days with the patch of comment #31 i had no problems. Do i have a handicap with the old algo?
Comment 32 Alex Deucher 2011-01-31 19:29:44 UTC
(In reply to comment #32)
> It seems to work fine for me. Since last days with the patch of comment #31 i
> had no problems. Do i have a handicap with the old algo?

No handicaps.  Just need to figure out which algo gives the best results for the most monitors for each asic.
Comment 33 Andrea Iob 2011-01-31 21:52:11 UTC
Patch from comment 31 works well also for me.
Comment 34 Alex Deucher 2011-02-03 00:14:17 UTC
I've sent the patches to Dave for 2.6.38 and 2.6.37 stable.
Comment 35 Florian Mickler 2011-02-03 08:20:45 UTC
Patch: https://bugzilla.kernel.org/show_bug.cgi?id=26552#c31
Comment 36 Helber Maciel Guerra 2011-02-08 00:38:08 UTC
This bug appear again on patch-2.6.38-rc3-git4, and is previous solved on 2.6.36-rc2-git2.

Can i provide more information, or do a git bisect?

Maybe is reintroduced on this commit:
commit bb5b583b52794efc7b59f70a78be1b66a98dd939
commit 811aaa55ba21ab37407018cfc01770d6b037d3fb

Device:
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc M880G [Mobility Radeon HD 4200] [1002:9712] (prog-if 00 [VGA controller])
	Subsystem: Acer Incorporated [ALI] Device [1025:027d]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at e0000000 (32-bit, prefetchable) [size=256M]
	Region 1: I/O ports at 3000 [size=256]
	Region 2: Memory at f0300000 (32-bit, non-prefetchable) [size=64K]
	Region 5: Memory at f0200000 (32-bit, non-prefetchable) [size=1M]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Kernel driver in use: radeon
Comment 37 Alex Deucher 2011-02-08 16:05:19 UTC
(In reply to comment #37)
> This bug appear again on patch-2.6.38-rc3-git4, and is previous solved on
> 2.6.36-rc2-git2.
> 
> Can i provide more information, or do a git bisect?

Yes, a bisect would be great.
Comment 38 Helber Maciel Guerra 2011-02-09 19:51:01 UTC
My git bisect log:

[root@note linux-git2.6]# git bisect log
git bisect start
# good: [ebf53826e105f488f4f628703a108e98940d1dc5] Linux 2.6.38-rc3
git bisect good ebf53826e105f488f4f628703a108e98940d1dc5
# bad: [100b33c8bd8a3235fd0b7948338d6cbb3db3c63d] Linux 2.6.38-rc4
git bisect bad 100b33c8bd8a3235fd0b7948338d6cbb3db3c63d
# bad: [78d2978874e4e10e97dfd4fd79db45bdc0748550] CRED: Fix kernel panic upon security_file_alloc() failure.
git bisect bad 78d2978874e4e10e97dfd4fd79db45bdc0748550
# good: [eb487ab4d5af0caee81bfaaa5d87b55844f60145] Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git bisect good eb487ab4d5af0caee81bfaaa5d87b55844f60145
# good: [811aaa55ba21ab37407018cfc01770d6b037d3fb] drm: Only set DPMS ON when actually configuring a mode
git bisect good 811aaa55ba21ab37407018cfc01770d6b037d3fb
# good: [e98ce0d7cfa6ee0650a63d45558a5121383995d9] Merge remote branch 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next into drm-fixes
git bisect good e98ce0d7cfa6ee0650a63d45558a5121383995d9
# bad: [18ff84da29b3f0c073e0ce6e341663cc6bcb0ab7] drm/radeon/kms/evergreen: always set certain VGT regs at CP init
git bisect bad 18ff84da29b3f0c073e0ce6e341663cc6bcb0ab7
# good: [f523f74eac1897b13c05c88ce6e5de0a7c34578b] drm/radeon/kms: add new pll algo for avivo asics
git bisect good f523f74eac1897b13c05c88ce6e5de0a7c34578b
# bad: [63a507800c8aca5a1891d598ae13f829346e8e39] drm/radeon: remove 0x4243 pci id
git bisect bad 63a507800c8aca5a1891d598ae13f829346e8e39
# bad: [619efb105924d8cafa0c1dd9389e9ab506f5425d] drm/radeon/kms: Enable new pll calculation for avivo+ asics
git bisect bad 619efb105924d8cafa0c1dd9389e9ab506f5425d





Result of git bisect:
[root@note linux-git2.6]# git bisect bad 
619efb105924d8cafa0c1dd9389e9ab506f5425d is the first bad commit
commit 619efb105924d8cafa0c1dd9389e9ab506f5425d
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Mon Jan 31 16:48:53 2011 -0500

    drm/radeon/kms: Enable new pll calculation for avivo+ asics
    
    New algo is used for r5xx+ and legacy is used for
    r1xx-r4xx, rv515.
    
    I've tested on all relevant GPUs and monitors that I
    have access to and have found no problems.
    
    Fixes:
    https://bugzilla.kernel.org/show_bug.cgi?id=26562
    https://bugzilla.kernel.org/show_bug.cgi?id=26552
    May fix:
    https://bugs.freedesktop.org/show_bug.cgi?id=32556
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Cc: stable@kernel.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>

:040000 040000 956a38aa4192356c3f0b7fe34cbf7af04a4a0342 18318beec8b390a01166edd311338f3ba819e823 M	drivers

Tanks, Helber Maciel Guerra
Comment 40 Helber Maciel Guerra 2011-02-10 00:20:27 UTC
OK. tested on git tree, solve problem.

Tanks, Helber Maciel Guerra.
Comment 41 Alex Deucher 2011-02-11 07:00:42 UTC
Helber, can you try the following patch instead of the two patches linked above?

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index cc6bdd8..2f9d113 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -562,7 +562,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
                                }
                        }
 /* this might work properly with the new pll algo */
-#if 0 /* doesn't work properly on some laptops */
+#if 1 /* doesn't work properly on some laptops */
                        /* use recommended ref_div for ss */
                        if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
                                if (ss_enabled) {
Comment 42 Alex Deucher 2011-02-11 07:32:14 UTC
Created attachment 47272 [details]
possible fix

Can everyone try the following patch against 2.6.38-rc4 or newer and make sure all is working well?
Comment 43 Helber Maciel Guerra 2011-02-11 19:41:42 UTC
(In reply to comment #42)
> Helber, can you try the following patch instead of the two patches linked
> above?
> 
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index cc6bdd8..2f9d113 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -562,7 +562,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
>                                 }
>                         }
>  /* this might work properly with the new pll algo */
> -#if 0 /* doesn't work properly on some laptops */
> +#if 1 /* doesn't work properly on some laptops */
>                         /* use recommended ref_div for ss */
>                         if (radeon_encoder->devices &
> (ATOM_DEVICE_LCD_SUPPORT)) {
>                                 if (ss_enabled) {

This patch work well.
Tanks, Helber Maciel Guerra.
Comment 44 Helber Maciel Guerra 2011-02-11 19:43:26 UTC
(In reply to comment #43)
> Created an attachment (id=47272) [details]
> possible fix
> 
> Can everyone try the following patch against 2.6.38-rc4 or newer and make
> sure
> all is working well?

This also patch work well.

Tanks again, Helber Maciel Guerra.
Comment 45 Alex Deucher 2011-02-12 01:14:23 UTC
Created attachment 47472 [details]
new patch

Can you try this patch?  Try uncommenting the following lines to see if either of those flags work any better.  Try them individually and together if possible and report back which, if any, helps.

/*pll->flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;*/

/*if (ASIC_IS_AVIVO(rdev))
        pll->flags |= RADEON_PLL_USE_FRAC_FB_DIV;*/
Comment 46 Helber Maciel Guerra 2011-02-12 03:07:57 UTC
(In reply to comment #46)
> Created an attachment (id=47472) [details]
> new patch
> 
> Can you try this patch?  Try uncommenting the following lines to see if
> either
> of those flags work any better.  Try them individually and together if
> possible
> and report back which, if any, helps.
> 
> /*pll->flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;*/
> 
> /*if (ASIC_IS_AVIVO(rdev))
>         pll->flags |= RADEON_PLL_USE_FRAC_FB_DIV;*/

I try to uncomment none, first, second and both.
In all cases, kernel fb run, but Xorg freeze.
I am using latest xf86-video-ati, drm and mesa from default git tree.

I don't try to start with ums, just kms.

Can be cause xorg freeze by kms, drm, xorg, radeon driver or combination?

Regards, Helber Maciel Guerra.
Comment 47 Alex Deucher 2011-02-12 07:26:54 UTC
(In reply to comment #47)
> 
> I try to uncomment none, first, second and both.
> In all cases, kernel fb run, but Xorg freeze.
> I am using latest xf86-video-ati, drm and mesa from default git tree.

It's likely a problem with some of the latest commits in xf86-video-ati, it's not a freeze, but command buffers getting rejected.  Try 6.14.0.
Comment 48 Alex Deucher 2011-02-12 10:37:28 UTC
(In reply to comment #48)
> 
> It's likely a problem with some of the latest commits in xf86-video-ati, it's
> not a freeze, but command buffers getting rejected.  Try 6.14.0.

xf86-video-ati git master should be fixed now.
Comment 49 Helber Maciel Guerra 2011-02-12 13:36:33 UTC
On the last i uncomment booth lines on kernel git.
Nothing changes, looks Xorg just stop.


The latest lines from Xorg.0.log:
[   258.037] (II) [KMS] Kernel modesetting enabled.
[   258.037] (**) RADEON(0): Depth 24, (--) framebuffer bpp 32
[   258.037] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
[   258.038] (==) RADEON(0): Default visual is TrueColor
[   258.038] (**) RADEON(0): Option "EnablePageFlip" "true"
[   258.038] (**) RADEON(0): Option "ColorTiling" "true"
[   258.038] (**) RADEON(0): Option "RenderAccel" "true"
[   258.038] (**) RADEON(0): Option "EXAPixmaps" "on"
[   258.038] (**) RADEON(0): Option "SwapbuffersWait" "on"
[   258.038] (==) RADEON(0): RGB weight 888
[   258.038] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
[   258.038] (--) RADEON(0): Chipset: "ATI Mobility Radeon HD 4200" (ChipID = 0x9712)

Nothing on dmesg too.

My xorg have this:
Is this relevant?

Section "Device"
	Identifier "hd4200"
	Driver "radeon"
	Option "ColorTiling" "true"
	Option "EnablePageFlip" "true"
	#Option "ScalerWidth" "2048"
	Option "RenderAccel" "true"
	Option "EXAPixmaps" "on"
	#Option "EXAVSync" "off"
	Option "SwapbuffersWait" "on"
	#Option "glXSwapBuffers" "on"
	#Option "AGPFastWrite" "on"
EndSection

Section "Screen"
	Identifier	"Default Screen"
	DefaultDepth	24
	SubSection "Display"
		Virtual	4886 1200
	EndSubSection
EndSection

What type of result i should expect?
Comment 50 Alex Deucher 2011-02-12 17:37:58 UTC
(In reply to comment #50)
> On the last i uncomment booth lines on kernel git.
> Nothing changes, looks Xorg just stop.

Does it only lock up with both lines uncommented or does any version of the patch lock up?  The patch by itself with both lines commented out is identical to the previous patch.  If that doesn't work, I'm not sure what is happening.  Maybe some build problem?
Comment 51 Helber Maciel Guerra 2011-02-12 21:31:31 UTC
(In reply to comment #51)
> (In reply to comment #50)
> > On the last i uncomment booth lines on kernel git.
> > Nothing changes, looks Xorg just stop.
> 
> Does it only lock up with both lines uncommented or does any version of the
> patch lock up?  The patch by itself with both lines commented out is
> identical
> to the previous patch.  If that doesn't work, I'm not sure what is happening. 
> Maybe some build problem?

Yes, is a build problem (my fault). I sorry about this.

Now i do all teste:
1 - pll->flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
2 - if (ASIC_IS_AVIVO(rdev)) pll->flags |= RADEON_PLL_USE_FRAC_FB_DIV;

Results:
1 - commented none - WORK.
2 - commented all - WORK.
3 - commented 1 - Not WORK.
4 - commentes 2 - WORK.

Regards, Helber Maciel Guerra
Comment 52 Rafael J. Wysocki 2011-02-12 23:16:38 UTC
Fixed by commit 619efb105924d8cafa0c1dd9389e9ab506f5425d .
Comment 53 Alex Deucher 2011-02-13 23:50:55 UTC
Created attachment 47732 [details]
final patch

Andrea, Daniel, Helber,

Thanks for all your help and testing.  The attached patch is what I am proposing goes upstream.  Please verify it works properly for your systems.
Comment 54 Helber Maciel Guerra 2011-02-14 01:05:44 UTC
OK, it works.

kernel(git), xf86-video-ati (git), libdrm (git),xorg-x11-server-Xorg.x86_64 (1.9.3-4.fc14)

01:05.0 VGA compatible controller [0300]: ATI Technologies Inc M880G [Mobility Radeon HD 4200] [1002:9712]

Tanks a lot, Helber Maciel Guerra.
Comment 55 Daniel 2011-02-17 15:57:53 UTC
I'm using kernel 2.6.38-rc5 (which includes the patch of comment #54) since yesterday without problems. The bug seems to be fixed for me. If not, i will report here.

Thanks for your time!
Comment 56 Hugh Daschbach 2011-02-21 00:56:21 UTC
I see that this is closed as fixed.  I've tested 2.6.38-rc5.  I still see flickering about once every thirty seconds on one head (analog) of a dual monitor desktop system.  Should I file a separate bug for this?


01:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350] (prog-if 00 [VGA controller])
        Subsystem: Hightech Information System Ltd. Device 2002
        Flags: bus master, fast devsel, latency 0, IRQ 45
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Memory at fbde0000 (64-bit, non-prefetchable) [size=64K]
        I/O ports at c000 [size=256]
        Expansion ROM at fbdc0000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: radeon
        Kernel modules: radeon
Comment 57 Alex Deucher 2011-02-21 04:28:06 UTC
(In reply to comment #57)
> I see that this is closed as fixed.  I've tested 2.6.38-rc5.  I still see
> flickering about once every thirty seconds on one head (analog) of a dual
> monitor desktop system.  Should I file a separate bug for this?

Is this a regression?  Is it the same commit(s) that's causing the problem for you?  Flickering at a fixed interval like 30 seconds sounds like something is polling the display on a regular basis.  Do you get the flickering in console before starting X or only after your desktop environment has loaded?
Comment 58 Hugh Daschbach 2011-02-21 05:28:52 UTC
Very insightful question, thanks.  The flickering goes away if I kill /usr/lib/upower/upowerd.

The flickering was not present when I boot to a text console.  It wasn't present when I started kdm.  It did start as soon as my desktop started loading.  It persisted even when I logged back out and switched to back to a text console.

But killing upowerd makes the flickering go away.

Many thanks.
Comment 59 Alex Deucher 2011-02-21 05:40:17 UTC
(In reply to comment #59)
> 
> But killing upowerd makes the flickering go away.

Ok, so it sounds like upowerd is polling the display every 30 seconds, so that is a upowerd bug rather than a driver bug.  The driver will generate an event when a monitor is connected or disconnected, so upowerd should not be polling the displays manually.
Comment 60 Andrea Iob 2011-02-22 21:03:28 UTC
2.6.38-rc5 works for me.

Thanks.