[Libdlo] defio mmap issues

[justin at dynam.ac]

> On Mon, Jan 11, 2010 at 6:57 AM, <justin at dynam.ac> wrote:
>
>> On a side note, and maybe for a latter email, I'm also getting
>> horizontal
>> artifacts on the screen after several hours of operations. Reading the
>> archives, I saw someone else post on this, and there was a thought there
>> was a race condition on the memmap. This is very reproducible for me
>> (takes about 1 hour though) so if I can provide further info to help
>> debug
>> that, I'm willing to take on the challenge!
>>
>
> Here are some datapoints from trying to track down this issue:
>
> * The problem happens both with the latest udlfb from git.plugable.com,
> and
> with jaya's original defio driver patch posted a few months back. So it
> could be a problem carried forward, but it doesn't look like a new problem
> ..
> * It can be seen more frequently with faster processors and larger
> screens.
> On my atom with 1920x1080, it's intermittent and small corruption.  On a
> faster Celeron with 3 1680x1050 screens, it starts happening quickly with
> any significant screen activity.
> * And a fun one: on that multi-screen setup, once you get large areas of
> the
> one screen (one DL device) to fail to render ... then moving the mouse and
> triggering rendering on the *other* DL device/screen, for the
> corresponding
> lines on the screen, refreshes the first device/screen properly (!)  Since
> udlfb keeps no shared state between different DisplayLink devices,
> apparently this confusion is happening at the defio/vma/page table level.
>
> Defio is used by several other framebuffer drivers, but perhaps not at
> these
> resolutions and not for multiple screens.  Has anyone seen other evidence
> that would support/contradict this being a general defio problem?  Or
> perhaps something simple/stupid that udlfb is doing to trigger it?
>
> Thanks,
> Bernie
>

Hi,
I did a quick test tonight with fbgrab, to see if a captured screenshot
also exhibited the same artifacts. It produces a perfectly clear picturem
so I guess that rules out any problems between application and the
Virtual(?) Framebuffer.

I've just commented out the backing_buffer code, to see if its got a issue
there.

Note, this is the first time I've delved into framebuffers and obviously
defio, I'm just trying what I can to rule out code in a effort to help
narrow down the possible suspects :) If my effort is wasted, let me know..
(but its a good learning experience along the way)

Thanks
justin