|Summary:||resolution 3840x1024 stopped to work on HD5850 after switch to 2.6.37 kernel|
|Product:||DRI||Reporter:||Peter Hercek <phercek>|
|Component:||DRM/Radeon||Assignee:||Default DRI bug account <dri-devel>|
|Status:||RESOLVED FIXED||QA Contact:|
|i915 platform:||i915 features:|
Description Peter Hercek 2011-02-21 07:24:37 UTC
Created attachment 43602 [details] example how root-tail output gets corrupted Resolution 3840x1024 stopped to work when I switched from 126.96.36.199 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
Comment 2 Peter Hercek 2011-02-21 07:26:23 UTC
Created attachment 43604 [details] xorg.log from 2.6.37
Comment 3 Peter Hercek 2011-02-21 07:27:05 UTC
Created attachment 43605 [details] dmesg from 188.8.131.52
Comment 4 Peter Hercek 2011-02-21 07:27:55 UTC
Created attachment 43606 [details] xorg.log from 184.108.40.206
Comment 5 Alex Deucher 2011-03-16 09:50:19 UTC
Does booting with radeon.disp_priority=2 help?
Comment 6 Peter Hercek 2011-03-16 12:15:23 UTC
Adding radeon.disp_priority=2 to the kernel command line did not help. It looks the same.
Comment 7 Alex Deucher 2011-03-16 23:45:20 UTC
This monitor is a matrox triplehead2go.
Comment 8 Alex Deucher 2011-04-08 08:56:06 UTC
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
Comment 9 Peter Hercek 2011-04-08 10:40:19 UTC
(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 220.127.116.11): 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)
Comment 10 Alex Deucher 2011-04-08 10:58:38 UTC
(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 > 18.104.22.168): > 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.
Comment 11 Peter Hercek 2011-04-08 11:15:01 UTC
(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?
Comment 12 Alex Deucher 2011-04-12 14:11:33 UTC
(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.
Comment 13 Alex Deucher 2011-04-12 14:25:56 UTC
Can you attach the full xrandr --verbose output?
Comment 14 Alex Deucher 2011-04-12 14:44:59 UTC
Created attachment 45556 [details] [review] possible fix Does this patch help?
Comment 15 Peter Hercek 2011-04-13 00:37:56 UTC
Created attachment 45562 [details] xrandr --verbose output on 22.214.171.124-vanilla (with 3840x1024 fixed using radeonreg regset 0x770c 0x00020004)
Comment 16 Peter Hercek 2011-04-13 01:37:03 UTC
(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 126.96.36.199-vanilla.
Comment 17 Alex Deucher 2011-04-14 09:30:02 UTC
Created attachment 45616 [details] [review] possible fix Does this patch help?
Comment 18 Peter Hercek 2011-04-14 15:44:43 UTC
(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.
Comment 19 Alex Deucher 2011-04-14 16:06:19 UTC
(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.
Comment 20 Peter Hercek 2011-06-18 15:31:08 UTC
Works well in 188.8.131.52; probably even in 2.6.39, but I did not try that.