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

Thomas Hellström thomas
Sun Mar 16 07:05:40 PDT 2008

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,
> Xavier

More information about the Openchrome-devel mailing list