On Sun, 08 Jan 2006 14:31:02 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote:
> Aapo Tahkola wrote: > >>>Alright. Have you been able to reproduce this with any other app? > >>>Perhaps if it hits in menus it might be able to track it down but I > >>>wouldnt try it otherwise. > >>>Also, does it lock always at the same time or is it random? > >>> > >> > >>No only Quake 3. in-game lockups are rare, most happens when loading > >>maps (might be locking up on the first frame) the worst map is Q3DM0, > >>which might help track it down. Also r_texturebits "32" vs. > >>r_texturebits "16" increases the chance of a lockup. > > > > > > Could you try Q3DM0 with this patch applied to r300_render.c ? > > It should ignore all rendering commands at around time leaving menu. > > Let me know if you cant reproduce the lock with it. > > > > BTW, "killall -15 quake3.x86; xrandr -s 0" might be handy if it doesnt > > lock... > > it does still lockup, I can kill quake3, but am unable to recover the > screen. the last screen is "loading SOUNDS"... So it doesnt hard lock system as it used to? If thats the case, then Im afraid states have something to do with the lock. >From r300 drivers point of view, texture depth doesnt really make much >difference. -- Aapo Tahkola ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
