Bug 34534

Summary: resolution 3840x1024 stopped to work on HD5850 after switch to 2.6.37 kernel
Product: DRI Reporter: Peter Hercek <phercek>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
example how root-tail output gets corrupted
none
dmesg from 2.6.37
none
xorg.log from 2.6.37
none
dmesg from 2.6.36.3
none
xorg.log from 2.6.36.3
none
possible fix
none
xrandr --verbose output on 2.6.38.2-vanilla (with 3840x1024 fixed using radeonreg regset 0x770c 0x00020004)
none
possible fix none

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 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
Comment 1 Peter Hercek 2011-02-21 07:25:49 UTC
Created attachment 43603 [details]
dmesg from 2.6.37
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 2.6.36.3
Comment 4 Peter Hercek 2011-02-21 07:27:55 UTC
Created attachment 43606 [details]
xorg.log from 2.6.36.3
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 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)
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
> 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.
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 2.6.38.2-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 2.6.38.2-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 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.