Created attachment 43602 [details] example how root-tail output gets corrupted Resolution 3840x1024 stopped to work when I switched from 2.6.36.3 to 2.6.37. The image looks like it is stretched by about 50% and it is corrupted. I did bisect it and the the commit when it appeared the first time is: f9d9c36204243d81e9d4dd28e58ee335257847d2 title: drm/radeon/kms: implement display watermark support for evergreen
Created attachment 43603 [details] dmesg from 2.6.37
Created attachment 43604 [details] xorg.log from 2.6.37
Created attachment 43605 [details] dmesg from 2.6.36.3
Created attachment 43606 [details] xorg.log from 2.6.36.3
Does booting with radeon.disp_priority=2 help?
Adding radeon.disp_priority=2 to the kernel command line did not help. It looks the same.
This monitor is a matrox triplehead2go.
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
(In reply to comment #8) xrandr reports the monitor on crtc 1 in both cases (working/non-working): DVI-1 connected 3840x1024+0+1050 (0x6b) normal (normal left inverted right x axis y axis) 1082mm x 288mm Identifier: 0x58 Timestamp: 12755 Subpixel: horizontal rgb Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 1 CRTCs: 0 1 2 3 4 5 Only time stamp is different in the above text block. 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)
(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.
(In reply to comment #10) > (In reply to comment #9) > does: > radeonreg regset 0x770c 0x00020004 > fix the broken state? 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?
(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.
Can you attach the full xrandr --verbose output?
Created attachment 45556 [details] [review] possible fix Does this patch help?
Created attachment 45562 [details] xrandr --verbose output on 2.6.38.2-vanilla (with 3840x1024 fixed using radeonreg regset 0x770c 0x00020004)
(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.
Created attachment 45616 [details] [review] possible fix Does this patch help?
(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.
(In reply to comment #18) > (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. Yes. > Here they are: > 0x0c00 0x00030002 (196610) > 0x0c04 0x2e985963 (781736291) > 0x7718 0x00100024 (1048612) > 0x771c 0x00100024 (1048612) > 0x770c 0x00020004 (131076) > > Thanks for fixing this. No problem. Sorry it took so long.
Works well in 2.6.39.1; probably even in 2.6.39, but I did not try that.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.