[Bug 35457] [rs690m] Graphics corruption with ati x1200

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Mar 15 19:33:58 PDT 2012


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

--- Comment #23 from d4ddi0 <stillcompiling at gmail.com> 2012-03-15 19:33:58 PDT ---
(In reply to comment #20)
> (In reply to comment #18)
> > I have not yet applied Alex's patch, [...]
> 
> Have you been able to test it in the meantime? It doesn't seem very likely
> it'll help, but...
>
I did finallly try the gart alignment patch (required a minor tweak,
gart.table.ram.ptr changed to gart.ptr) 
No change and no line in dmesg. 

> > BTW, I am a C programmer... If I knew where to start, I'd love to work on this
> > problem from a code angle. I've looked at the code somewhat, but even in the
> > code specific to my driver there is a lot of code in different places.
> 
> See e.g. rs690_mc_init() in drivers/gpu/drm/radeon/rs690.c .

Thanks! I am poking around in drm/radeon. I wonder if it is possible to step
through loading radeon.ko in gdb... There is no serial port on this puppy

(In reply to comment #21)
> Might also be related to bug 37679 (interrupt problems).  Can you try a similar
> patch to the ones on that bug?

The quirks in bug 37679 seem to just force msi.
Thesymtos do not seem to apply. interrup count steadily rises with glxgears. I
also booted with radeon.msi=1 (which has the same effect). No difference other
than being assigned a different irq
(In reply to comment #22)
> I have a packard bell dot m/a (radeon x1270) and have the issue described in
> this bug. My setup:
>  * kernel 3.2
>  * libdrm 2.4.30
>  * mesa 7.11.2
> 
> I replaced the bios with a modded one that allow tweaking of video ram type. I
> tried two settings: uma only and uma+sideport.
> 
>  * UMA (256M)
>    * No graphic corruption
>    * No laggy window movement
>    * glxgear fps ~= 360
> 
>  * UMA+sideport (256M+64M)
>    * Massive graphic corruption
>    * Laggy window movement
>    * glxgears fps ~= 200
> 
> A diff between dmesg output:
> $ diff dmesg.uma dmesg.uma+sideport 
> 9c9
> < [drm] Detected VRAM RAM=256M, BAR=256M
> ---
> > [drm] Detected VRAM RAM=384M, BAR=256M
> 11c11
> < [drm] radeon: 256M of VRAM memory ready
> ---
> > [drm] radeon: 384M of VRAM memory ready
> 15c15
> < [drm] PCIE GART of 512M enabled (table at 0x000000006C180000).
> ---
> > [drm] PCIE GART of 512M enabled (table at 0x000000006B800000).
> 31a32
> > [drm] radeon: power management initialized
> 
> Hope it can help. I can make more test if needed.

That 384 number seems like the most likely suspect.
I see indications several places that theres only 64M of sideport VRAM, but 384
== 128 + 256

I'm not sure where that specific piece of data (the 128M of internal vram) is
coming from, or whether it can be "fixed" by poking 64 * 1024 * 1024 into some
register...
I tried arbitrarily setting rdev->mc.real_vram_size to 320M as soon as it was
set, but that had no effect

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the xorg-driver-ati mailing list