Created =
attachment 69483 [details]
dmesg showing oom gpu lock and drm errors
HD4890 on (old) 32 bit LFS with 4(3.3) gig mem.
This one takes about 20 minutes to show and longer to oom (if it does).
ETQW 1920x1080 with all settings on/turned up sitting on commit -
commit b6521801070d52bdd5908824e82c1ce2dde16e8e
Author: Marek Ol=C3=85=C2=A1=C3=83=C2=A1k <maraeo@gmail.com>
Date: Mon Sep 17 23:22:00 2012 +0200
r600g: don't snoop context state while building shaders
Let's use the shader key describing the state.
The game initially runs OK, but after some time (15-20 mins) when
spectating/following a bot switching between bots to force a new part of the
map to load provokes short stalls for a couple of seconds which are not pre=
sent
when the game first runs.
Spectating a bot that is flying so seeing a large part of the map also star=
ts
stalling - 1/4 to 1/2 second stalls.
This happens with or without --enable-r600-llvm-compiler, though the oom was
produced without.
Eventually when switching bots to force different parts of map to load some
temporary rendering errors like black ground appear then after more time and
switching oom-killer + gpu lock as in dmesg provided.
After oom I lost X screen, though vts/fbcon was OK restarting X didn't reco=
ver
- vt7 still showing mangled game scene.
The WARNING and seamonkey errors in the attached dmesg are "normal for=
me" and
were way before the problem (and also before a 60 minute issue free etqw run
while sitting on the commit before this one).