[Openchrome-devel] K8M800 artifacts, trac #145, trac #164
Sun Mar 16 06:45:02 PDT 2008
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.
>> Andrey Melentyev wrote:
>>> Here's the commitdiff:
>> (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?
> Hi, Benno.
> (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 ?
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 ?
More information about the Openchrome-devel