Commen=
t # 41
on bug 55692<=
/a>
from Christian K=C3=B6nig
(In reply to comment #=
37)
> Created attachment 68728 [deta=
ils]
> dmesg.3.7-rc1 with testpatch with mesa-git
>=20
> I removed gdm and installed slim as login manager. Also installed cinn=
amon
> as a replacement for gnome and it works fine the first round with linu=
s git
> with the test patch and mesa git. Restarted slim and logged in again a=
nd
> there were some font corruptions, i restarted cinnamon and they were g=
one. I
> tried google maps with webgl enabled and it was working fine.
>=20
> After that i edited my .xinitrc to startup gnome, restarted slim and l=
ogged
> in but it failed and got the error window saying oh no something has g=
one
> wrong and a log out button. I checked dmesg at that point and saw the =
ttm
> gart memory error. i switched back to cinnamon logged in and got the s=
ame
> font corruptions, restarting cinnamon fixed them.
Thanks allot for your additional testing, as I suspected we are really faci=
ng
two problems here:
1. The new gnome/gdm versions seem to trigger an out of memory situation in
the GART memory area. That's probably because some miscalculation or memory
leak or something like this and should be handled as a separate bug.
BTW: You can take a look at the current memory allocations with:
sudo cat /sys/kernel/debug/dri/0/radeon_gtt_mm
and
sudo cat /sys/kernel/debug/dri/0/radeon_vram_mm
2. Properly updating the page table asynchronously somehow fails under high
memory pressure.
I will try to look into problem 2 first, since that got added with my patch.
But problem number 1 is as equally as bad.
I don't think we just spool up allot of drawing operations like Jerome
suspected, cause in this case TTM would just block on previous render
operations to complete. It looks more like we are submitting a single draw
operation with multiple ~16MB chunks of memory that is so big that it just
won't fit into the GART memory altogether.