[Openchrome-devel] K8M800 artifacts, trac #145, trac #164

[Thomas Hellström]

Xavier Bachelot wrote:
> Thomas Hellstr?m wrote:
>> Benno Schulenberg wrote:
>>> Hello Thomas,
>>>
>>> In trac tickets #145 and #164 two people seemingly independently
>>> found kernel commit a0a6dd0b221260be1e3da725e6b49797e5fa7429
>>> (DRM commit 6c04185857694b2293046b7ea1d4515404a740c3) to be the 
>>> cause for screen corruptions they see on K8M800 and VN800 chips.
>>>
>>>   http://www.openchrome.org/trac/ticket/145
>>>   http://www.openchrome.org/trac/ticket/164
>>>
>>> Andrey Melentyev wrote:
>>>  
>>>> Here's the commitdiff:
>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a0a6dd0b221260be1e3da725e6b49797e5fa7429 
>>>>
>>>>     
>>> (So, Xavier, it appears you were right in your suspicion that it was 
>>> a kernel change that causes this.  :)
>>>
>>> Is there anything in the diff that leaps at you, Thomas?  Or should 
>>> the reporters file a bug against DRM so you can look at it later?
>>>
>>> The following two statements seem strange to me:
>>>
>>>    (void) *paused_at;
>>>
>>>    ptr = ((volatile char *)paused_at - dev_priv->dma_ptr) + ...
>>>
>>> What are they supposed to do?
>>>
>>> Benno
>>>   
>> Hi, Benno.
>> The
>>  (void) *paused_at
>>
>> thingy is to read back a dword from AGP, to make sure the 
>> write-combining buffers on the processors are flushed before handing 
>> the AGP data over to the device.
>>
>> The ptr assignment is where the AGP command reader is supposed to 
>> stop if it stops after the previous command submission.
>>
>> Anyway, I have a K8M800 here, and I have just pushed a fix to drm 
>> that seems to cure the AGP DMA problems I was seeing. Could you check 
>> back with the openChrome-users?
>>
> This is excellent news. I unfortunately can't try this myself as I 
> don't have neither a K8M800 nor a VM800, but I'll post to the mailing 
> list to get some feedback and I'll also try to PM some of the 
> reporters. Do you know if other chipsets can be affected too Thomas ?
Yes, I think so, considering I used a K8M800 and CN400 to test these 
things out. Strangely enough I only saw regressions when I upgraded my 
system very recently.
>
> In case this proves to be the correct fix, do we still have any chance 
> to get this pulled into 2.6.25 kernel or is it already too late ?
I can ask Dave Airlie, but before that, we need confirmation quickly 
that the new code indeed works.
Regards,

/Thomas

>
> Regards,
> Xavier
>