[Openchrome-users] 3D -> laptop freezes - K8M800 (ubuntu dapper - acer 1362)

[Thomas Hellström]

Benno Schulenberg wrote:

>Jean-Patrick Pommier wrote:
>  
>
>>How can I be sure that the computer is using the newly build
>>driver?
>>    
>>
>
>Remove the old one.  Or move it to where X won't find it, to the 
>homedir of root, for example.
>
>  
>
>>If the build driver is buggy, is there some news 
>>regarding a possible fixing of that bug ?
>>    
>>
>
>Thomas said that the unichrome part of Mesa is unmaintained.  :(
>
>  
>
>>(can I fix the problem 
>>myself by compiling something : latest mesa, kernel ...?)
>>    
>>
>
>The problem lies in Mesa, that's the thing handling textures.  
>Lately there was some talk of some texture stuff being broken:
>
>https://bugs.freedesktop.org/show_bug.cgi?id=6814
>
>See comment #30.
>
>That same day Keith Whitwell posted a patch to mesa3d-dev that 
>should fix... something.  The post isn't in the archives yet, they 
>appear to stop at May 4th, so I can't link to it.  And I don't know 
>if this fix made it into CVS already.  You could pull the most 
>recent CVS and see if the fragment below has been applied; if so, 
>the rest will have been too.  Then compile and install and see if it 
>makes a difference.
>
>diff -u -r1.35 via_ioctl.c
>--- drivers/dri/unichrome/via_ioctl.c   16 Nov 2005 17:24:26 -0000      
>1.35
>+++ drivers/dri/unichrome/via_ioctl.c   5 May 2006 09:25:27 -0000
>@@ -233,7 +233,7 @@
>     
>    if (mask & BUFFER_BIT_STENCIL) {
>       if (vmesa->have_hw_stencil) {
>-        if (ctx->Stencil.WriteMask[0] == 0xff) {
>+        if ((ctx->Stencil.WriteMask[0] & 0xff) == 0xff) {
>            flag |= VIA_DEPTH;
>            clear_depth &= ~0xff;
>            clear_depth |= (ctx->Stencil.Clear & 0xff);
>
>Benno
>  
>
Hi!

This patch is to fix some broken stencil tests that got broken when the 
default Mesa stencil WriteMask got changed to 0xffffffff. Doesn't help 
with the locking problem.

Actually I don't think it's a unichrome dri driver bug that is causing 
the crashes, but rather undocumented timing issues with the K8M800 
chipset. Note that the 3D driver was written for and tested with the 
CLE266 chipsets. That it works as well as it does with later chipsets is 
pure luck. Often chipset manufacturers introduce bugs that have to be 
worked around in the most obscure ways.

The unichrome dri driver puts textures in AGP memory and the 2D driver 
initializes AGP to 8x at startup. It is possible that the K8M800 can't 
really cope with that. Also, I remember seeing some (timing ?) register 
tweaks for K8M800 in VIA's 2D driver.

Thomas

>_______________________________________________
>openchrome-users mailing list
>openchrome-users at openchrome.org
>http://wiki.openchrome.org/mailman/listinfo/openchrome-users
>Main page:
>http://www.openchrome.org
>Wiki:
>http://wiki.openchrome.org
>User Forum:
>http://wiki.openchrome.org/tikiwiki/tiki-view_forum.php?forumId=1
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wiki.openchrome.org/pipermail/openchrome-users/attachments/20060511/bf331a1d/attachment-0001.html