Bug 26552

Created attachment 43292 [details]
dmesg when there is no flickering

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

I think this is probably a duplicate of bug 26562.

new_pll=0 became the default in 2.6.37.

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)

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

Created attachment 43332 [details]
lspci -v

Created attachment 43342 [details]
vbios

Created attachment 43362 [details]
possible fix

Does this patch fix the issues?

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

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))

Created attachment 43432 [details]
alternate patch

Can you try this patch as well instead of the patch in comment 8?

Both patch of comment #8 and patch of comment #11 fix my problem. 

Thanks for your time.

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!

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.

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.

@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?

@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?

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

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

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.

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.

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?

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

Up to now (5 reboots), with patch in comment 8 plus patch in comment 20 there is NO flickering.

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.

Sorry for the second post, i've forgotten: I had no more white line flickering!

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.

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.

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.

Created attachment 45272 [details]
new consolidated patch

It's probably just easier to stick with the old algo for rv515.  Try this patch out.

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?

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

Patch from comment 31 works well also for me.

I've sent the patches to Dave for 2.6.38 and 2.6.37 stable.

Patch: https://bugzilla.kernel.org/show_bug.cgi?id=26552#c31

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

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

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

The following patches should fix it:
http://lists.freedesktop.org/archives/dri-devel/2011-February/007976.html
http://lists.freedesktop.org/archives/dri-devel/2011-February/008059.html

OK. tested on git tree, solve problem.

Tanks, Helber Maciel Guerra.

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) {

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?

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

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

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;*/

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

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

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

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?

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

(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

Fixed by commit 619efb105924d8cafa0c1dd9389e9ab506f5425d .

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.

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.

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!

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

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

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.

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

2.6.38-rc5 works for me.

Thanks.