https://bugs.freedesktop.org/show_bug.cgi?id=34534

--- Comment #2 from Peter Hercek phercek@gmail.com 2011-02-21 07:26:23 PST --- Created an attachment (id=43604) --> (https://bugs.freedesktop.org/attachment.cgi?id=43604) xorg.log from 2.6.37

https://bugs.freedesktop.org/show_bug.cgi?id=34534

--- Comment #4 from Peter Hercek phercek@gmail.com 2011-02-21 07:27:55 PST --- Created an attachment (id=43606) --> (https://bugs.freedesktop.org/attachment.cgi?id=43606) xorg.log from 2.6.36.3

https://bugs.freedesktop.org/show_bug.cgi?id=34534

--- Comment #6 from Peter Hercek phercek@gmail.com 2011-03-16 12:15:23 PDT --- Adding radeon.disp_priority=2 to the kernel command line did not help. It looks the same.

https://bugs.freedesktop.org/show_bug.cgi?id=34534

--- Comment #8 from Alex Deucher agd5f@yahoo.com 2011-04-08 08:56:06 PDT --- Can you dump the following registers in both the working and non-working states using radeonreg or avivotool (http://cgit.freedesktop.org/~airlied/radeontool/)? You only need to dump the set that aligns to whichever crtc you are using for the problematic monitor (probably crtc 0 if you have just one monitor attached). 'xrandr --verbose' will tell you which crtc is in use.

crtc0: radeonreg regmatch 0x0bf0 radeonreg regmatch 0x0bf4 radeonreg regmatch 0x6b18 radeonreg regmatch 0x6b1c radeonreg regmatch 0x6b0c

crtc 1: radeonreg regmatch 0x0c00 radeonreg regmatch 0x0c04 radeonreg regmatch 0x7718 radeonreg regmatch 0x771c radeonreg regmatch 0x770c

crtc 2: radeonreg regmatch 0x0c10 radeonreg regmatch 0x0c14 radeonreg regmatch 0x10318 radeonreg regmatch 0x1031c radeonreg regmatch 0x1030c

crtc 3: radeonreg regmatch 0x0c20 radeonreg regmatch 0x0c24 radeonreg regmatch 0x10f18 radeonreg regmatch 0x10f1c radeonreg regmatch 0x10f0c

crtc 4: radeonreg regmatch 0x0c30 radeonreg regmatch 0x0c34 radeonreg regmatch 0x11b18 radeonreg regmatch 0x11b1c radeonreg regmatch 0x11b0c

crtc 5: radeonreg regmatch 0x0c40 radeonreg regmatch 0x0c44 radeonreg regmatch 0x12718 radeonreg regmatch 0x1271c radeonreg regmatch 0x1270c

https://bugs.freedesktop.org/show_bug.cgi?id=34534

--- Comment #10 from Alex Deucher agd5f@yahoo.com 2011-04-08 10:58:38 PDT --- (In reply to comment #9)

As for as the registers for crtc 1:

Just before the watermark commit - the good case (and it is the same as 2.6.36.3): 0x0c00 0x00030002 (196610) 0x0c04 0x00000000 (0) 0x7718 0x00000000 (0) 0x771c 0x00000000 (0) 0x770c 0x00020004 (131076)

Just at the watermark commit - the bad case: 0x0c00 0x00030002 (196610) 0x0c04 0x2e985963 (781736291) 0x7718 0x00000024 (36) 0x771c 0x00000024 (36) 0x770c 0x00010005 (65541)

does: radeonreg regset 0x770c 0x00020004 fix the broken state? If not, try replacing the other values with the working versions to narrow down which ones are problematic or if they all need to be changed.

https://bugs.freedesktop.org/show_bug.cgi?id=34534

--- Comment #12 from Alex Deucher agd5f@yahoo.com 2011-04-12 14:11:33 PDT --- (In reply to comment #11)

Yes, it does. Only the one regset is enough. Do you think I can just add this to some xserver startup script so that I have a workaround for now? Would it be safe?

yes, it's fine.

https://bugs.freedesktop.org/show_bug.cgi?id=34534

--- Comment #14 from Alex Deucher agd5f@yahoo.com 2011-04-12 14:44:59 PDT --- Created an attachment (id=45556) View: https://bugs.freedesktop.org/attachment.cgi?id=45556 Review: https://bugs.freedesktop.org/review?bug=34534&attachment=45556

possible fix

Does this patch help?

https://bugs.freedesktop.org/show_bug.cgi?id=34534

--- Comment #16 from Peter Hercek phercek@gmail.com 2011-04-13 01:37:03 PDT --- (In reply to comment #14)

Does this patch help?

No, the image stays corrupted, I still need to do this to fix it: # radeonreg regset 0x770c 0x00020004 OLD: 0x770c (770c) 0x00010005 (65541) NEW: 0x770c (770c) 0x00010004 (65540) #

I applied and tested the patch with 2.6.38.2-vanilla.

https://bugs.freedesktop.org/show_bug.cgi?id=34534

--- Comment #18 from Peter Hercek phercek@gmail.com 2011-04-14 15:44:43 PDT --- (In reply to comment #17)

Does this patch help?

Yes, this patch works. 0x770c is set to the right value now. 0x7718 and 0x771c are different than before too but that is probably intended. Here they are: 0x0c00 0x00030002 (196610) 0x0c04 0x2e985963 (781736291) 0x7718 0x00100024 (1048612) 0x771c 0x00100024 (1048612) 0x770c 0x00020004 (131076)

Thanks for fixing this.

https://bugs.freedesktop.org/show_bug.cgi?id=34534

Peter Hercek phercek@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED

--- Comment #20 from Peter Hercek phercek@gmail.com 2011-06-18 15:31:08 PDT --- Works well in 2.6.39.1; probably even in 2.6.39, but I did not try that.